注意
1つのフロー定義では、異なる言語（COBOLまたはJava）のアプリケーションを相互に連携させることはできません。連携させるアプリケーションの言語は、統一するように定義してください。
本節で示すフローに関する図では、COBOLまたはJavaのどちらか一方の言語によるアプリケーション連携を例に説明します。
■フロー定義の範囲と階層化
フロー定義を作成する場合に1つのフロー定義に多くのアクティビティを収めると、フローの流れが複雑になり管理が大変になります。アクティビティは最大で256個まで指定できますが、1つのフロー定義で設定するアクティビティの数は10個以下を推奨します。
まず、業務のフローを設計する場合にフロー定義を行う範囲を考えます。結果受信を行う場合は、タイムアウトも停止することもなく実行できる業務を、1つのフロー定義として設計してください。
大規模なフローを設計する場合は以下のようにフローの階層化を行ってください。できるかぎりフローの再利用性を考慮し、問題が発生した場合に切り分けができるように設計してください。
また、補償ルートが発行された場合など、全体としての整合性を考慮して設計してください。
以下に階層化したフローの設計例とフロー設計の基準を示します。
注文フロー定義では、在庫の有無を判断して在庫がない場合には、発注処理を行うような業務フローを定義してあります。発注業務では、発注物の内容によって国内注文または海外に注文をするような業務フローとなっています。また、注文フロー定義が親フローとなって、発注アプリケーションから新たに発注フローを開始するような子フローを定義してあります。発注アプリケーションは、子フローの図にあるようなフロー業務の業務処理開始アプリケーションとして動作し、親フローの処理の延長として新しいフロー業務を開始させます。
■補償処理を考慮した設計
補償ルート上に取消し処理用業務処理実行アプリケーションの定義がない場合、補償処理メッセージは、何も処理をしないで、次の補償ルートへルーティングされます。
以下に例を示します。
上図のように補償ルート上に存在する業務処理実行アプリケーションで取消し処理を定義していない場合は、補償処理メッセージを受信しても何も処理されず、通過することになります。
異常が発生した業務処理実行アプリケーションでは、取消し処理は呼び出されません。
以下に概念図を示します。
上図に示すようにアプリケーションDで異常が発生した場合は、アプリケーションC・B・Aの取消し処理が呼び出されます。
異常が発生した業務処理実行アプリケーションは処理がロールバックされるため、異常地点の取消し処理は呼び出されません。
そのため、上図のアプリケーションDのように、出力している実行ルートに補償ルートが設定されていないアプリケーションへ取消し処理を定義しても、呼び出されることはありません。
Javaの場合、補償ルートを実行する異常と除外する異常に指定した例外は、派生クラスも対象となります。
補償ルートを実行する異常と除外する異常について、運用のパターン例を以下に示します。
上図の例の場合、補償ルートが実行される異常はExceptionA、ExceptionB、ExceptionCとなり、補償ルートから除外される異常はExceptionD、ExceptionEになります。
ExceptionEは、基底クラスにExceptionDをもつため補償処理から除外されます。
上図の例の場合は、ExceptionEだけが除外される異常となり、その他の異常は補償ルートが実行されます。
上図の例のように最上位のExceptionを指定すると、補償処理を行うとしたExceptionBも含め、すべての異常で補償処理から除外されるので、注意してください。
以下の場合も補償処理を行うとしたExceptionで補償ルートは発行されません。
上図の場合、ExceptionCの基底クラスに除外するExceptionBが含まれているため、補償ルートを実行する異常としたExceptionCで補償ルートは発行されません。
■優先度制御機能
メッセージに優先度を設定する機能です。業務処理を優先して行いたい要件が発生した場合や業務処理中に一定の条件を満たした場合などに、特定のメッセージの優先度を変更することができます。
優先度によるメッセージ処理順序の変更は、業務に関連付けられたキュー単位で行います。キューからメッセージを取り出す際、複数のメッセージが格納されている場合、優先度が高いメッセージから優先的に取り出されます。これにより、優先度が高いメッセージは優先度が低いメッセージよりも優先的に処理されます。優先度はメッセージごとに指定可能なため、同一フロー定義であっても異なった優先度のメッセージが作成できます。
優先度は以下の指定ができます。
レベル
高い
普通
低い
なお、特に指定しない場合は、[普通]として動作します。
優先度の指定方法を以下に示します。
メッセージの起点で優先度を指定：
メッセージを発行するAPIに優先度のレベル([高い]、[普通]、[低い])を指定してメッセージを発行します。
起点のユーザアプリケーションからメッセージを発行する際、送信するメッセージの内容により優先度を選択することができます。優先度は、メッセージの中継点で変更されるまで発行時に設定された優先度で動作します。
設定方法については、“6.2.3.1 フローを起動するAPIの組込み”を参照してください。
メッセージの中継点で条件式に合致するメッセージの優先度を変更：
フロー定義ツールで設計するルーティングの各ルートに、優先度を変更するための条件式と変更する優先度のレベルを定義することができます。メッセージを各ルートで送信する際、メッセージの内容から条件式を評価し、trueとなるメッセージの優先度を指定された優先度に変更します。優先度は、一端変更されると次に再変更する条件に合致するまで変更された優先度で動作します。
設定方法については、“5.2.4.5 条件ルートの設定”の“■メッセージ優先度の設定”を参照してください。
優先度の指定方法における概念図を以下に示します。
注意
補償ルートとして発行されるメッセージの優先度を変更することはできません。補償ルートメッセージは最優先で処理されます。
同報・条件分岐、または代行分岐を間にはさむルートにおいて、分岐へ入力するルートと分岐から出力するルートで異なるメッセージ優先度が設定されている場合、実行時には出力するルート側のメッセージ優先度が有効になります。
例として、下図のように同報・条件分岐、および代行分岐を含むフローが定義されている場合に、分岐から出力するそれぞれのルートで実行時に設定されるメッセージ優先度を示します。
分岐へ | 分岐から | 分岐から | 分岐から出力するルートの | 分岐から出力するルートの |
|---|---|---|---|---|
(1) | (3) | 条件ルート | (1)で設定されたメッセージ優先度 | (3)で設定されたメッセージ優先度 |
(1) | (4) | 実行ルート | (1)で設定されたメッセージ優先度 | (4)で設定されたメッセージ優先度 |
(1) | (5) | 条件ルート | (1)で設定されたメッセージ優先度 | (5)で設定されたメッセージ優先度 |
(2)または(3) | (6) | 実行ルート | (2)または(3)で設定されたメッセージ優先度 | (6)で設定されたメッセージ優先度 |
(2)または(3) | (7) | 代行ルート | (6)と同じメッセージ優先度 | |
■sendMessageSyncメソッドのタイムアウト
Javaの場合、待ち合わせ型のフローを起動するAPIにおいて、sendMessageSyncメソッドが復帰するまでの最大の待ち時間を設定することができます。タイムアウトに設定した時間を過ぎても処理結果を取得できない場合、APIはnullを返却します。設定方法については、“6.2.3.1 フローを起動するAPIの組込み”を参照してください。
■フローのタイムアウト機能
フローのタイムアウト機能は、メッセージ発行ごとに有効期間を設定し、有効期間を過ぎたメッセージ処理を自動的に停止することができる機能です。
タイムアウトしたメッセージは、フロー定義ツールの異常定義で指定された後処理が実施され、エラーメッセージ退避キューなどへの退避が行われます。メッセージの退避が発生した場合、処理結果のメッセージが業務処理開始アプリケーションに送信されます。突き放し型の場合は、処理結果の取得APIを使用した時点で異常を検出することができます。また、待ち合わせ型の場合は、異常メッセージが到着した時点で業務処理開始アプリケーションへ復帰し、異常を検出することができます。
タイムアウト時間は、業務アプリケーションの実行時間と待ち時間を考慮して、余裕をもって設定する必要があります。設定方法については、“6.2.3.1 フローを起動するAPIの組込み”を参照してください。
フローのタイムアウト機能の方式を以下に示します。
タイムアウト判定方式
メッセージの発行時間からタイムアウト時間の経過を絶対時間で判定する方式です。たとえば、有効期間を30秒で指定し、10時00分00秒でメッセージが発行された場合、10時00分31秒以降で行われるタイムアウト判定処理でタイムアウト異常になります。そのため、ルーティング中に閉塞キューなどが存在した場合など、ほとんどルーティングされていないメッセージに対してタイムアウト異常となる可能性があります。
有効期間の範囲は、メッセージの発行からフローの終点のアクティビティへメッセージが到達するまでの時間になります。メッセージ処理中に異常が発生した場合の後処理や補償処理メッセージ処理中にタイムアウトの判定は行われません。
また、タイムアウトの判定は、メッセージがルーティングされる各非同期アプリケーション連携実行基盤が行います。
上図で示すように、非同期アプリケーション連携実行基盤がメッセージを受信時、および次のルーティング先へメッセージを送信する直前にタイムアウト判定を行います。そのため、キューにメッセージが滞留している間、および業務ロジックの処理中などでタイムアウト判定は行われません。
注意
フローのタイムアウト機能では、各アプリケーションサーバの時刻を元にタイムアウトの判定が行われます。そのため、複数のアプリケーションサーバを使用する運用を行う場合は、アプリケーションサーバの時刻を同期させることを推奨します。時刻が同期していない場合は、フローのタイムアウトが発生する経過時間がずれることになります。
ループ処理の注意
上図のようにアクティビティの処理をループさせることが可能ですが、ループされるルートの場合は、必ず分岐を含めて無限ループにならないよう設計してください。
無限ループに陥ったときの異常を検知するため、メッセージがアクティビティを通過できる最大数を設定することができます。詳細については“5.2.5.1 異常処理定義画面の概要”を参照してください。
結果受信キューを定義する場合の注意
上図のように、業務処理開始アプリケーションから業務処理実行アプリケーションを通過せずに、結果受信キューへメッセージを送信することがないように設計してください。フローの実行時、業務処理開始アプリケーションから業務処理実行アプリケーションを通過せずに結果受信キューにメッセージがルーティングされる場合、フローは開始されずエラーとなります。
■セキュリティ設計
セキュリティ設計については、“Interstage Business Application Server セットアップガイド”の“セキュリティの設計”を参照してください。
