テレコム課金、Java EE、GWT、Salesforce.comの交差点について話したい — フラットデザインが流行り始め、レスポンシブCSSがトレンドかどうか誰もが議論していた頃の2013年中頃の組み合わせとしてこれ以上ないものだ。しかしここに事実がある：実際のお金を処理した実際のテレコムオペレーター向けにこのスタックで本物のソフトウェアを出荷した。そして、その環境で学んだことの非自明な量は今でも適用可能だ。なぜなら根本的な問題は構造的であり、技術的ではないからだ。

BluLogixはCloud Innovation Suite — テレコムオペレーター向けのクラウド課金プラットフォーム — を構築した。私の仕事はバックエンド開発、フロントエンド監督、BPMNワークフロー設計、そして最も示唆に富んだTalend ETL経由でのCISとSalesforce.comのインテグレーションだった。最後の部分がこの投稿の大部分を費やしたいところだ。エンジニアリングが本当に面白くなった場所だからだ。

テレコム課金が実際にどんな様子か

SalesforceインテグレーションがテレコムBillingシステムにとってなぜ難しいかを理解するには、テレコム課金が実際に何であるかのおおまかなモデルが必要だ。

テレコム課金は請求書ではない。継続的にイベントをレート付けするシステムだ — 通話、データセッション、SMSメッセージ、APIコール、クラウドリソース消費 — 商品カタログに対して、価格ルールとディスカウントを適用し、サブスクリプション状態を管理し、サイクル中変更（プランアップグレード、日割り請求、アドオン）を処理し、課金サイクルで繰り返し料金を実行し、規制準拠の請求書を生成し、支払いを処理し、紛争を処理し、収益保証レポートを生成する。単一のエンタープライズ顧客の課金サイクルには、数千万の使用イベント、数百のレートプランを持つ商品カタログ、複数の通貨、複数の国にまたがる税管轄が含まれる可能性がある。

これがテレコム課金システムが特化したソフトウェアカテゴリとして存在する理由だ。スプレッドシートではできない。QuickBooksではできない。データモデルは汎用財務ソフトウェアとは根本的に異なる。

GWT — Google Web Toolkit — は2013年にJavaエンジニアが型安全でテスト可能でJavaScriptをよく知る必要なしにリッチなウェブインターフェースを構築する方法だった。Javaを書き、GWTがJavaScriptにコンパイルし、IDEの型チェッカーはスタック全体で機能した。2013年、TypeScriptが存在する前でモダンなフロントエンドフレームワークが成熟する前、これは本当に合理的なトレードだった。出力JavaScriptは冗長でデバッグサイクルは遅かったが、Java中心チームの開発者体験は代替手段よりも良かった：JavaエンジニアがPHPと同じ熱意を持って扱うような生のJavaScript。GWTは今は消えた。それで構わない。2013年、Java EEショップでエンタープライズソフトウェアを構築するにあたって、それは正しいツールだった。

Salesforceがあなたのビリングシステムを嫌う理由

SalesforceのデータモデルはいくつかのCRM抽象化を中心に構築されている：アカウント、コンタクト、オポチュニティ、プロダクト。このモデルは営業プロセスに卓越して機能する。テレコム課金にはみじめなフィットだ。

具体的な例を挙げよう。Salesforceでは、アカウントは会社だ。オポチュニティは潜在的な売上だ。プロダクトは売るものだ。オポチュニティがクローズすると、オーダーになり、プロダクトはそのオーダーの一部になる。

テレコム課金システムでは、「顧客」は複数のアカウント（子会社ごとに一つ）を持つかもしれず、各アカウントは複数のサブスクリプションを持ち、各サブスクリプションは異なる課金サイクルと価格ティアを持つ複数のレートコンポーネントを含む複数のサービスバンドルで構成される可能性がある。「営業チームが売ったもの」と「課金システムがレート付けして請求書を発行しているもの」の関係は、Salesforceの標準オブジェクトが単純に表現しない多対多だ。

これら二つのシステムを統合するよう求められたとき — 一方にCIS、他方にSalesforce — 最初のフェーズは技術的ではない。分類学的だ。SalesforceのコンセプトをCISのコンセプトにマッピングし、マッピングがない場所、コンセプトが近似的にのみ等価な場所、ミスマッチがあまりにも根本的で一方にカスタムオブジェクトを作る必要がある場所を文書化するために数週間を費やす。

BluLogixでは、ETLレイヤーにTalend Open Studioを使っていた。TalendはビジュアルなプランETLツールだ：変換コンポーネントの有向グラフとしてデータフローを構築し、Talendが基礎となるJavaコードを生成する。ビジュアルモデルはインテグレーションロジックを理解して承認する必要があるステークホルダーに役立つ。生成されたコードが実際に実行されるものだ。「ステークホルダーがビジュアルモデルで承認したもの」と「課金サイクルの初日の午前3時に生成されたコードがヒットするエッジケース」のミスマッチが、給料を稼ぐ場所だ。

課金ワークフローのためのBPMN

CISプラットフォームはビジネスプロセス定義にBPMNを使った — 偶然ではなく、後でCamundaを使ってTalenteraで使うのと同じワークフローモデルだ。テレコム課金には複雑な条件付き状態がある：サブスクリプションはアクティブ、停止中（未払い）、停止中（顧客リクエスト）、終了、ポート、転送されることがある。状態間の遷移にはビジネスルールがある：終了したサブスクリプションは再アクティブ化できない、未払いによる停止は任意の停止とは異なる再アクティブ化フローをトリガーする。これらのルールは管轄と商品タイプによって異なる。

BPMNはこのための正しいモデリング言語だ。代替案は課金エンジンに埋め込まれたハードコードされた状態マシンロジックで、すべてのルール変更がコードデプロイを意味する。BPMNでは、特定の規制市場の停止から再アクティブ化ワークフローを変更するのはプロセス定義のデプロイであり、コードデプロイではない。コンプライアンスチームはJavaを読む代わりにBPMN図を直接レビューできる。これは理論的な利点ではない — コンプライアンスレビューのタイムラインは週単位で測られ、「このワークフローを更新するために課金エンジンを再デプロイする必要がある」はすべてのコンプライアンス変更に週を加える。

Spring Securityレイヤーは課金プラットフォームの内部サービス全体のアクセス制御を処理した。Spring WSはSOAPサービスインターフェースをカバーした — 2013年、SOAPはまだエンタープライズインテグレーションの共通語で、ターゲットにしていた大手テレコムオペレーターはSOAPを話してWSDLを期待するミドルウェアを持っていた。GWTフロントエンドはSpring MVCエンドポイントと通信した。これは当時の標準的なJava EEアーキテクチャだった。設計上つまらない。

実際に重要だったETL作業

TalendベースのSalesforceインテグレーションには一つのコア要件があった：Salesforceでセールスディールがクローズされたとき（オポチュニティがClosed Wonに移動）、対応するサブスクリプションと課金設定が手動データ入力なしにCISに作成される必要があった。テレコム課金での手動データ入力は収益漏洩が起きる場所だ。見落とされたディスカウント設定、間違った課金サイクル日付、誤って設定された商品バンドル — これらはソフトウェアをクラッシュさせるバグではない。誤った請求書を引き起こす。誤った請求書は紛争を生む。紛争は時間を消費し顧客の信頼を侵食する。エンタープライズ契約が年間数百万ドルに達するテレコムでは、誤った請求書は存続問題だ。

これを処理するTalendジョブはスケジュールで実行され、SOAP API（後にSalesforceがAPIサーフェスを拡張するにつれてREST APIに）経由でSalesforceをポーリングし、まだCISにプロビジョニングされていないClosed Win状態のオポチュニティを引き出し、オポチュニティと関連するプロダクトデータをCISサブスクリプションオブジェクトに変換し、課金設定を作成し、レコードをプロビジョニング済みとマークした。エラーハンドリングはハッピーパスよりも複雑だった：部分的な失敗は重複サブスクリプションを作ることなく再試行可能である必要があった。Salesforceのバルク操作の並行性モデルを尊重する必要があった。CISトランザクションモデルはサブスクリプション作成と課金設定にわたってアトミック性を保証する必要があった。

入った時に誰も教えてくれなかった部分：SalesforceのデータモデルはそのAPIドキュメントが意味するよりも可変だ。異なる管理者によって異なる期間に設定された異なるSalesforce組織は、異なるフィールドレイアウト、異なるカスタムフィールド、異なるバリデーションルールを持つ。ある組織に対して完璧に機能するインテグレーションは、デプロイされるすべての組織に対して再検証が必要だ。Talendジョブに変換を試みる前にソースデータの形状を検証するバリデーションステップを組み込んだ。これにより失敗は破損したCISレコードとしてではなくデータ品質エラーとして表面化した。そのバリデーションステップはデプロイごとに約一回のデータインシデントを救った。

テレコムの課金顧客に出荷することについて

何かが間違っていると電話してくれる顧客への出荷でしか得られないエンジニアリング経験のカテゴリがある。チケットを出すではなく、電話する。テレコムオペレーターはオペレーションセンターを持っている。課金が壊れているとき、そのオペレーションセンターの誰かがそれを知っていて、誰に電話するかを知っていて、電話してくる。

それが生み出す説明責任は明確化する。投機的なインフラは出荷しない。モニタリングできないものは出荷しない。機能の前に運用ツールを構築する。誰かが電話してきたとき、10分以内に答えを出せる必要があることを知っているからだ。テレコム課金での注意の標準は、間違っていることのコストがドル単位で定量化できるため、ほとんどのSaaSカテゴリよりも本当に高い。

実際のテレコム課金イベントを処理した。実際の顧客データを課金システムとCRM間で移動するインテグレーションを出荷した。GWTとJava EEとTalendとBPMNで、Spring SecurityとSpring WSと今では古く見えるXML重めの世界でやった。

世界はそれほど変わっていない。Salesforceはインテグレーションしようとするすべての特化したシステムと同じデータモデルのミスマッチを依然として持っている。課金システムは依然として内部でイベント駆動の状態マシンだ。BPMNは依然としてコンプライアンス駆動のワークフローのための正しいツールだ。技術スタックは変わった。問題は同じだ。

古いスタックで作業する方法を知っている。なぜそれがその選択をしたかを知っている。それは聞こえるほどまれなことだ。