 |
|
|
| 1 2 3 4 次のページ
|
|
| はじめに
|
前回、ビジネス・プロセス・インテグレーション（BPI：Business Process Integration）は単なるシステム統合技術としてではなく、サービス・オリエンテッド・アーキテクチャ（SOA：Service Oriented Architecture）の中のコンポーネントとして位置づけることで企業戦略を支える重要な技術であることを解説した。
今回はBPIのためのソリューションがなぜ必要なのか、どのような意味を持つのかを具体的に説明していく。
|
| BPIの特徴と要件
|
まずはBPIの実行時における特徴を考えてみる。前回で、BPIを「複数システム間での処理を連携させて、プロセスとして統合することにより、ビジネス的に意味のある一連の作業の『End To End』での自動化を実現すること」と定義した。
これを「複数システムの連携」「ビジネス的に意味のある一連の作業の自動化」の2つに分けて考えていく。
|
| 複数システムの連携
|
従来、多くの業務システムは特定部門の業務を支援するよう設計・開発されてきた。単一のシステムで業務が完結するのであれば、それでだけ十分である。連携によってオーバーヘッドが発生することもなく、効率的に業務が行えるだろう。しかしながら、昨今のめまぐるしい経営環境の変化によって、業務システムに対する要求は多様化し、複数のシステムをまたがる業務が多く存在するようになってきている。このため、様々なシステム連携の仕組みが考えられてきた。人手による連携／バッチジョブ連携／EAIなどがあり本連載で解説するBPIもその1つである。
まずは複数システムの連携の要件として、連携するシステムのアーキテクチャおよびインターフェースの違いを吸収する必要がある。
今日、単一のシステムアーキテクチャで構成されたシステムしかない企業などはほとんどない。多くの企業が昔からのホスト系システムやオープン系のシステム、またはパッケージ製品などの様々なシステムを使って業務を行っている。一見、業務的には単一システムで行われているように見える場合でも、マスターデータは別のシステムと連携している場合が多いのである。
また、1つの組織の中のシステムだけでは終わらない業務も多数存在する。自身の組織内だけでなく他の会社（同じグループ会社、取引先の会社、アウトソーシング委託先の会社など）と連携することも少なくない。
このように違ったシステム間で連携するために必要な要件として、以下の項目をあげることができる。これらの各項目について、さらに詳しく考えていく。
- データ変換・セマンティック変換
- お互いのシステムで理解できるようにデータを変換する要件
- 処理のコントロール
- 業務処理にあった順序・タイミング・条件で処理をコントロールする要件
- 長時間にわたる処理
- 長時間にわたるプロセス処理になりうることを想定する要件
- オープンな仕組み
- 連携の仕組みのオープン性の要件
|
表1：システム間で連携するための必要な要件
|
| データ変換・セマンティック変換
|
お互いのシステムで理解できるようにデータを渡すためには、物理的なネットワークのレイヤーからプロトコル、セマンティックにいたるまでのすべてのデータが変換される必要がある。
これができて、はじめて意味のある処理が可能になるのである。特にBPIで重要となるのがセマンティック変換であるが、単純に相手のフォーマットに変換するだけのものから、変換テーブルが必要なもの、そのテーブルを自動的にメンテナンスする必要があるもの、などの要件が存在する。
例えば、システムAでは取引先の国をあらわすのに国番号として整数値を使用していて、システムBでは略字3文字で国をあらわしていたとする。この2つを変換するためには、国番号と略字3文字との変換テーブルが必要である。なぜなら、単純な規則だけであらわすことができないからである。ここで今まで取引したことのない国の取引先ができたとき、システムAに新しい国番号とシステムBに新しい略字3文字を追加した場合、変換テーブルも追加しないと新しい国に対して変換することはできない。このような変換の場合には、変換テーブルのメンテナンスという要件も必要なのである。
そして、このような変換の要件を解決するBPIシステムの機能として「データマッピング機能」がある。
図1：データマッピング機能の例
- システムAから受け付けたデータをデータ変換層の国番号テーブルを参考にして共通なデータに変換した後、ビジネスプロセスに渡す
- ビジネスプロセス内では共通データのみをあつかい、システムBを呼び出すときにはデータテーブルを参照してシステムB用のデータに変換してから呼び出し、戻りデータはシステムBが共通データに変換してからビジネスプロセスが受け取る
- もし新たに国番号を追加する必要がある場合には、国番号テーブルに新しい行レコードを追加する
表2：データマッピング機能の例
このような国番号テーブルは更新頻度が低く、スタティックなテーブルを使用して「データマッピング機能」によって対応可能となる。
また別の例として、システムAとシステムBとで顧客情報を管理していたとする。システムの中では一人の顧客を識別するのにキーがアサインされているが、一般的には別のシステムでは別のキーがアサインされている。先ほどの国の例と同じように、同じ顧客をシステムAとシステムBの間でキーの変換テーブルを使用すればシステムAとシステムBの変換ができる。
ここで先ほどと同じように新しい顧客を追加した場合を考えてみる。システムAに顧客を追加して、システムBにも顧客を追加する。これは変換テーブルもメンテナンスすれば変換可能である。しかし顧客の追加が頻繁に行われるとすると、その度にメンテナンスしていたのでは業務がまわらない。そもそもBPIを使って自動的に連携しようとしているのに、連携のためのメンテナンスが頻繁に発生してしまっては本末転倒である。
この問題を解決するためには、新しい顧客が追加された際に変換テーブルの追加も自動的にされればよい。また削除された場合にも変換テーブルの自動的な削除が必要になる。このような場合、変換テーブルの自動的なメンテナンスという要件も必要なのである。そして、このような要件を解決する機能として「リレーションシップ機能」がある。具体的には以下のようになる（図2、表3）。
図2：リレーションシップ機能の例
（画像をクリックすると別ウィンドウに拡大表示します）
- システムAに新たな顧客（鈴木太郎さん）が追加され、その情報がシステムAより送られてくる。データ変換層ではシステムAの顧客ID（A12345）をキーに顧客ID変換テーブルを検索するがデータが存在しないので、変換テーブルにそのキーと共通用の顧客ID（設定された変換ロジックを元に生成）を追加する
- 共通用データに変換後、ビジネスプロセスでデータを受け取り、システムBに対してデータを送付する。データ変換層では顧客ID（012345）をキーに変換テーブルでシステムB用の顧客IDを検索するが存在しないので、システムBに対して顧客追加の呼び出しを行う
- システムB内では、送られたデータを元に顧客追加の処理を行い、新しく顧客IDを採番する。そして、システムB内の顧客テーブルに新しい顧客レコードが追加される
- 採番された顧客IDが返り値として戻される。データ変換層の顧客ID変換テーブル内にシステムB用顧客IDがセットされる
表3：リレーションシップ機能の例
このように、顧客IDのように変更頻度が比較的高い場合には、動的テーブルを使用した「リレーションシップ機能」で対応可能になる。
なお、これらの「データマッピング機能」や「リレーション機能」は、システム連携においてデータの差異を吸収するものであることから、両方まとめて「メディエーション機能」とも呼ばれている。
|
1 2 3 4 次のページ
|
|
|
|
|
著者プロフィール
日本アイ・ビー・エム株式会社 小倉 弘敬
日本アイ・ビー・エムソリューション開発 インテグレーション所属
ソフトウェア・エバンジェリスト。担当分野は、ビジネス・プロセス・インテグレーション（BPI:Business Process Integration）。WebSphere Business Integration（WBI）ソリューションセンターで、BPIソリューションの開発／提供に従事する。
|
|
著者プロフィール
日本アイ・ビー・エム株式会社 佐藤 泉
入社以来、ワークフロー、ビジネスプロセスエンジン、ビジネスプロセスモニターなどのソフトウェア製品の開発やそれらの製品をベースとしたソリューションの提案活動に従事。
特に、SOAに則ったBPI（Business Process Integration）やBIO（Business Innovation and Optimization）を得意分野とする。
|
|
|
|
|
|
