ルーティング・プロダクションの設計モデル
この章では、InterSystems のユーザがインタフェース・ルーティング・ソリューションを構築するために使用した設計モデルについて説明します。このモデル自体を、ルーティング・プロダクションの開発のためのベスト・プラクティスのコレクションと見なすことができます。
この章では、1 つのアプローチのみを説明します。その他の実装計画でも同様に成功を収めることができます。各組織には、コードの記述およびプログラミング・プロジェクトの実施に関する独自の標準があります。この章では、InterSystems IRIS® に特有で、入念に体系化されたアプローチによって利点を得られるルーティング・プロダクションの側面について簡単に説明します。
一般に、優れた設計にとって重要な点は、明確さと簡潔さです。簡潔さとは、部分の数の少なさではありません。簡潔さとは、モデル内の各部が明確な機能を持ち、直感的に探しやすいことを意味します。
構成項目
プロダクションは構成項目より構成されます。構成項目には以下の 3 タイプがあります。
-
ビジネス・サービスは、受信メッセージを受け付けます。
-
ビジネス・オペレーションは、送信メッセージを送信します。
-
ビジネス・プロセスは、その中間のすべての処理を指示します。ビジネス・プロセスにはいくつかの特殊なタイプがあります。
ルーティング・プロセスは、ルーティング・プロダクションの以下の主要なコンポーネントを呼び出すことにより、メッセージのルーティングおよび変換を行います。
-
ルーティング・ルールは、メッセージのコンテンツに基づいてメッセージを宛先に送ります。
-
スキーマ・カテゴリは、メッセージのコンテンツの検証およびアクセスの手段を提供します。
-
データ変換は、変更を適用し、宛先に向けてメッセージを準備します。
シーケンス・マネージャは、関連するメッセージが適切なシーケンスとタイミングでターゲットに到達するようにします。
以下の図は、ルーティング・プロセスのダイアグラムを拡大したもので、このプロセスがルーティング・ルールを使用してインタフェースでの情報のフローを指示する方法を示しています。以下の図には、上のダイアグラムの点線の円で示された部分のみのルーティング・ルールおよびデータ変換の詳細が示されています。
ルーティング・プロセスには、ルーティング・ルール・セットが関連付けられています。ルール・セットの定義方法、およびソース・アプリケーションから着信するメッセージのタイプにより、ルール・セットは実行するルールを特定します。複数のルールを順に実行することもできますが、説明を簡易化するため、以下の図にはルール・セットが 1 つのルールのみを選択する場合を示します。図のように、ルールはここからメッセージを削除することも、InterSystems IRIS 内の宛先に送信することもできます。この宛先がビジネス・オペレーションの場合、メッセージはプロダクションからターゲット・アプリケーションに送信されます。
アプリケーションの仕様
観念的に言えば、アプリケーションは、アプリケーションが送信 (または受信) できるメッセージのタイプ、およびこれらのイベントについてアプリケーションが送信 (または要求) するメッセージ・セグメントおよび各セグメントの部分を説明する、アプリケーション仕様ドキュメントまたは実装ガイドを提供します。
この種の公式ドキュメントは、非常に詳しく、非常に有用です。仕様ドキュメントが利用可能な場合、アプリケーションの管理者は、これをユーザに示したり、可能性のある多くのメッセージのうち、どれが実際に企業内で使用されているのかを説明することができます。
アプリケーション仕様ドキュメントがなくても、通常は非公式ドキュメントがあります。アプリケーション管理者に、使用可能なドキュメントを参照させてもらうよう依頼してください。
ドキュメントの代替として、または既存のドキュメントが正しいことを検証するため、メッセージ自体を調査して、アプリケーションが送信または受信要求するタイプを決定することができます。アプリケーション管理者に、ファイルに保存されたメッセージ・データのサンプリングの提供を依頼してください。
これらのタスクをサポートする背景情報については、このドキュメントの後続の章および以下のドキュメントを参照してください。
プロダクション・スプレッドシート
情報システムを編成するスプレッドシートをアプリケーションごとに管理するのは有用なことです。一般的なガイドラインとして、送受信データを提供する各アプリケーションの行を作成します。それぞれの行では、以下の列が有用です。
-
[フィード] — インタフェース・エンジンまたはサーバでは、いくつかのアプリケーションからのメッセージをルーティング・プロダクションに送ることがよくあります。このような場合、エンジンまたはサーバの名前をここに記します。
-
[アプリケーション] — 特定のアプリケーション、システム内でのロール、およびこのアプリケーションの問題についての連絡先を簡単に指定します。InterSystems IRIS を使用していないがシステムの動作については大まかに理解している組織のメンバが理解できる説明であることが理想的です。
-
[名前] — このアプリケーションに対する 3 ～ 6 文字の一意の名前。
-
[タイプ] — アプリケーションが外部の通信に使用するプロトコル。
-
[接続] — IP アドレスやポート番号など、接続の詳細。
-
[送信] — このアプリケーションが情報システムに提供するメッセージ構造。
情報システムに入った後の受信メッセージの構造を考慮してください。宛先のシステムまたはその他の要因によって異なるルーティングまたは変換を行う必要があるでしょうか。その必要がある場合、必要な数だけこれをリストし、相違点に関する注釈を付けます。このようにして、スプレッドシートは、それぞれの場合で必要なルーティング・ルール、データ変換、およびカスタム・スキーマを作成する際のチェックリストとして機能します。
-
[受信] — このアプリケーションが情報システムから利用するメッセージ構造。
-
[ACK] — 確認応答の詳細。ACK および NACK メッセージを必要としますか。これらのメッセージを送信および受信するための個別のインタフェースがありますか。プロダクションで ACK および NACK を生成する必要がありますか。もしくは受信アプリケーションで生成しますか。
プロジェクトの開始時、最初のスプレッドシートに情報システム内のすべてのアプリケーションについて記述する必要はありません。新規インタフェースを導入するごとにスプレッドシートに追加することができます。
インタフェース設計
このトピックでは、インタフェース設計をモジュール式にして、開発の各段階においてプロダクションを容易に理解、拡張、および管理するための効果的な方法を説明します。
-
InterSystems IRIS にメッセージを送信するアプリケーションごとに 1 つのビジネス・サービスを提供する。これは、プロダクション・スプレッドシートの [送信] 列に 1 つ以上のエントリがあるアプリケーションです。
1 つのビジネス・サービスは、同じアプリケーションのすべてのメッセージ構造を受信できます。通常、これが適切な設計です。この目的でビジネス・サービスを設定する場合、一般的にはビジネス・サービスをそのアプリケーション・システムに常時接続します。
同じアプリケーションに対してさらにビジネス・サービスの接続が必要となる構成がある場合もあります。例えば、ソース・アプリケーションが既に異なる 2 つの TCP/IP ポートにメッセージを送信するよう設定されている場合、1 つのポートからのすべてのメッセージを受信するよう 1 つのビジネス・サービスを設定し、別のポート用にもう 1 つのビジネス・サービスを設定します。1 通信ソースあたり 1 ビジネス・サービスであるため、これは一般的にアプリケーションごとに 1 ビジネス・サービスというモデルと一貫しています。
一方、同じ医療アプリケーションを使用する何百人ものユーザがデータを企業に送信している場合、これらすべてのメッセージを 1 つのビジネス・サービスにより (アプリケーションの単一のインスタンスに常時接続されているかどうかによらず) InterSystems IRIS にルーティングすると便利なこともあります。
-
ビジネス・サービスごとに 1 つのルーティング・プロセスを提供する。ルーティング・プロセスでは、メッセージ自体のコンテンツまたは InterSystems IRIS に保存された情報に基づいて、メッセージをルーティングすることができます。ルーティングが別のメッセージのコンテンツに依存する場合、またはルーティングの決定に外部アプリケーションの呼び出しを必要とする場合は、ルーティング・プロセスは別のクラスを呼び出す BPL ビジネス・プロセスである必要があります。ただし、ほとんどの場合は、組み込みのルーティング・ルール・エンジンに基づくルーティング・プロセスで十分です。
-
プロダクションからメッセージを受信するアプリケーションごとに 1 つのビジネス・オペレーションを提供する。これは、プロダクション・スプレッドシートの [受信] 列に 1 つ以上のエントリがあるアプリケーションです。
1 つのビジネス・オペレーションは、同一アプリケーションに対してすべて異なるメッセージ構造を送信できます。通常、これが適切な設計です。この目的でビジネス・オペレーションを設定する場合、一般的にはビジネス・オペレーションをそのアプリケーション・システムに常時接続します。ただし、ビジネス・サービスの場合、このモデルにバリエーションがある場合があります。
基本概念は、一貫したモジュール式設計です。つまり、一度に 1 つのインタフェースを開発し、インタフェースごとに 1 つのルーティング・プロセスを使用します。これは、単一の大規模なルーティング・プロセスがすべてのインタフェースのルーティング・エンジンとして機能するモデルとは対照的です。ルーティング・プロセスが 1 つより多い方が優れている理由はいくつかあります。
-
1 つのインタフェースで必要なケースのみに対応すればよいため、それぞれのルーティング・ルール・セットの管理が単純かつ容易である。自己完結した、簡単な一連の問題を解決する作業を共有および再利用する方が容易です。
-
インタフェースの個別の開発、置換、および管理が容易になる。企業が特定のアプリケーションを削除またはアップグレードする必要がある場合、かかわりが必要になるのは、このアプリケーションを処理するルーティング・プロセスのみです。インタフェースがダウンした場合、そのインタフェースを無効化、診断、修正、および再テストするだけで、これを再起動することができます。
これは、大規模なルーティング・プロセスで 1 つのインタフェースを追加、削除、または修正する必要が生じるたびにすべてのルールを再テストし、検証する必要性に比べ、非常に簡潔です。このような考慮事項は、一部のインタフェースを動作させる一方で、その他はまだ開発中である場合に特に重要となります。既に稼動中のルーティング・プロセスに追加するたびに、何百もの既存のルールを再テストし、検証する必要が生じる可能性があるのです。下の図は、複数のインタフェースを持つルーティング・プロダクションを示しています。
プロダクションの各構成項目には、果たすべき特定のロールがあります。各項目にそのロールを遂行させます。
-
ビジネス・サービスおよびビジネス・オペレーションは簡単にする。一般に、ビジネス・サービスまたはビジネス・オペレーションに対して独自のコードを記述する必要はありません。InterSystems IRIS が提供する組み込みクラスを選択してください。この選択により、自動的に正しいアダプタが指定されます。管理ポータルの設定を使用してこれらのクラスを構成します。
-
複雑なアクティビティはすべてルーティング・プロセスの制御下に配置する。インタフェースが単純な場合、そのルーティング・プロセスを複雑にする必要はありません。しかし、複雑なアクティビティが存在する場合、それはビジネス・サービスやビジネス・オペレーションではなく、ルーティング・プロセスに所属させます。タスクを実行するため、ルーティング・プロセスは別のルーティング・プロセスに連鎖するか、ビジネス・ルール、ルーティング・ルール、データ変換、ビジネス・プロセス、またはカスタム・コードを呼び出すことができます。
命名規則
このトピックでは、命名規則の重要性について説明し、その例を示します。
一般に、プロダクションは、一度に 1 インタフェースずつ、付加的に開発します。項目は “その都度” 命名し、命名規則をプロジェクトの進行に伴って増やしていくという考えもありますが、命名規則にはこのような付加的アプローチを取らないことをお勧めします。
HIS システム全体には数百ものインタフェースが関与する可能性があることに注意してください。これらのインタフェースがすべて含まれた場合のルーティング・プロダクションの管理タスクを予想してください。各コンポーネントの名前は、その目的を明確に示す必要があります。このようにすることで、開発者とシステム管理者は、機能に基づいてコンポーネントの名前を容易に予測することができます。
命名規則は一式すべてプロジェクトの開始時に確立し、その後はこれらに従うことをお勧めします。これによって、名前を修正するだけのためにプロダクション構成に戻る必要性が軽減されます。
機能別に明確にコンポーネントを特定できる規則であれば問題ありません。InterSystems ユーザが使用し、成功を収めている命名規則一式を以下に示します。
-
構成項目名に関する規則は、"プロダクションの構成" の “構成名” を参照してください。
-
名前を作成するために組み合わせる個々のセグメントをリストします。具体的な内容は次のとおりです。
-
名前の各セグメントは簡潔にする (3 ～ 6 文字)
-
名前は大文字と小文字を区別する
プロダクションの要素ごとに、定義したセグメントから名前を組み立てます。
-
ビジネス・サービス ： FromSourceAppName
-
ビジネス・オペレーション ： ToTargetAppName
-
ルーティング・プロセス ： SourceAppNameRouter
-
ルーティング・ルール・セット ： SourceAppNameRules
-
データ変換 ：
SourceAppNameSourceMessageTypeToTargetAppNameTargetMessageType
-
カスタム・スキーマ・カテゴリ ： SourceAppNameBaseSchemaNumber
さらに複雑な設計の場合は以下のようになります。
-
ビジネス・サービス ： FromSourceAppNameMessageTypes
-
ビジネス・オペレーション ： ToTargetAppNameMessageTypes
-
ルーティング・プロセス ： SourceAppNameMessageTypesRouter
-
ルーティング・ルール・セット ： SourceAppNameMessageTypesRules
以下のトピックでは、これらの命名規則について説明し、例を示します。
ビジネス・サービス
規則
例
FromERChart、FromFineOR、FromDeskAdm
バリエーション
1 つのアプリケーションが複数のビジネス・サービスを介してメッセージを InterSystems IRIS に送信するようインタフェースを編成する場合は、各ビジネス・サービスを通過する MessageTypes を分類するキーワードも含めます。一般的な MessageTypes キーワードでは、メッセージ構造の最初の 3 文字を使用します。この場合、ビジネス・サービス名の規則は、FromSourceAppNameMessageTypes となります。
ルーティング・プロセス
規則
例
ERChartRouter、FineORRouter、DeskAdmRouter
1 つのアプリケーションが複数のビジネス・サービスを介してメッセージを InterSystems IRIS に送信するようインタフェースを編成する場合は、各ビジネス・サービスを通過してルーティング・プロセスに渡される MessageTypes を分類するキーワードも含めます。この場合、ルーティング・プロセス名の形式は以下のとおりです。
バリエーション
例
ERChartADTRouter、ERChartORMRouter、ERChartOtherRouter
ルーティング・ルール・セット
規則
各ルーティング・プロセスには関連付けられたルール・セットがあり、これらのルールによってメッセージの宛先が特定されます。ルールはメッセージ・タイプ、メッセージのコンテンツ、時刻、その他の要素に基づき、メッセージをデータ変換またはビジネス・オペレーションに送ります。各ルール・セットは、そのルーティング・プロセスに適した名前で命名します。つまり、各 SourceAppNameRouter に対し、ルール・セットは SourceAppNameRules とします。各 SourceAppNameMessageTypesRouter に対し、ルール・セットは SourceAppNameMessageTypesRules とします。
例
DeskAdmRules
DeskAdmORMRules
ビジネス・オペレーション
規則
例
ToImagit、ToFineOR、ToPindex
バリエーション
1 つのアプリケーションが複数のビジネス・オペレーションを介して InterSystems IRIS からメッセージを受信するようインタフェースを編成する場合は、各ビジネス・オペレーションを通過する MessageTypes を分類するキーワードも含めます。
カスタム・スキーマ・カテゴリ
規則
ApplicationName の BaseSchemaNumber
ApplicationName は、送信アプリケーションまたは受信アプリケーションを表すことができます。
