使用する前に
ここでは、ADK のインストール、ADK の構造、アダプタのコンパイル、およびアダプタの導入について説明します。
JDK のインストール
Sun または IBM の説明に従って、Java Development Kit をインストールします。サービス カタログ（Service Catalog）で動作が保証されているのは、JBoss 7.1.1 のインストール環境では Sun JDK 6、WebSphere 7.0.0.17 のインストール環境では IBM Java 1.6 です。
ADK のインストール
ADK のインストール方法は次のとおりです。
1.
管理者 ：製品パッケージのコンテキストを展開し、image/isee/dist フォルダにある adk.zip を探し、その場所をアダプタ開発者に知らせます。
2. アダプタ開発者 ：ファイル adk.zip（または adk.tar.gz）を管理者から入手します。
3. アダプタ開発者 ：ADK パッケージをローカル マシン（C:\ADK）で展開します。C ドライブにする必要も、ADK ディレクトリにする必要もありません。ただし、この章の例では C:\ADK です。
ADK 構造
ADK をインストールすると、次のサブディレクトリが作成されます。
表 6-1 ADK のサブディレクトリ
|
|
|
<root> |
ビルド プロシージャ ファイルが格納されます。 |
ant |
ANT ビルド システム一式が格納されます。この ANT は標準の Apache ANT ビルド システムであり、追加の拡張がいくつか含まれています。 |
doc |
java doc サブディレクトリが格納されます。ADK ドキュメントをここに配置できます。 |
doc\javadoc |
javadoc 形式の ADK のヘルプ。 |
example |
アダプタのサンプルが格納されます。 |
example\src |
サンプル アダプタのソース ファイル Java ファイルが格納されます。 |
example\deploy |
そのアダプタについて記述された adapter.xml が格納されます。 |
lib |
コンパイルに必要な ADK ライブラリが格納されます。 |
アダプタは ADK 主構造のサブディレクトリです。インストール後の example も、そのようなアダプタの 1 つです。アダプタのコードは、次のような構造にする必要があります。
表 6-2 アダプタ コード構造表
|
|
|
<adapter> |
アダプタの短縮名。サンプル アダプタの場合は example です。 |
<adapter>\src |
必須。ソース Java ファイルのルート。 |
<adapter>\deploy |
必須。導入ディレクトリ。ここには、 adapter.xml というファイルが格納されている必要があります。 |
<adapter>\lib |
これはオプションです。 ISEE.war の lib ディレクトリに追加する、追加ライブラリ。 |
<adapter>\config |
これはオプションです。 ISEE.war のクラス ディレクトリにコピーされる追加ファイル。 |
この例では、 src および deploy だけです。
ファイルをコンパイルした後、ステージング ディレクトリを作成します（アダプタの作成方法については、次の項を参照してください）。ステージング ディレクトリは、作成手順を使用して後から削除および再作成できます。
表 6-3 ディレクトリの説明表
|
|
|
staging |
実稼働ディレクトリのルート。 |
staging\classes |
アダプタのコンパイルされた Java クラス。 |
staging\adapters |
各アダプタのビルド済み jar が格納されます。アダプタの名前は、adapter_<adaptershortname>.jar となります。 |
staging\config |
各アダプタの config サブディレクトリにあったファイル。 |
staging\deploy |
それぞれの deploy サブディレクトリのファイル名は、<adaptershortname>.xml に変更されます。 |
staging\lib |
各アダプタの lib サブディレクトリにあったファイル。 |
staging\dist |
最後の isee.adapters の展開可能なファイル。 |
アダプタのソース構造の作成
新しいアダプタを作成するには：
手順 1 前述のようなディレクトリ構造を作成します。
手順 2 ソースを作成し、構造内に配置します。
手順 3 adapter.xml を作成し、deploy ディレクトリに配置します。詳細については、adapter.xml 記述子についてを参照してください。
手順 4 オプションで、追加のライブラリおよび追加のコンフィギュレーション ファイルを追加します。
手順 5 build.properties を変更し、使用するアダプタをアダプタの行に追加します。これにより、作成したディレクトリを検索するよう ANT が設定されます。
コンパイル手順では、このビルドをバージョン管理に追加することができ、後でインストール前にコンパイルできます。
アダプタのコンパイル
アダプタを作成した後、次を実行することによってアダプタをビルドします。
build.cmd （UNIX システムの場合は ./build.sh ）
最終的な生成物が、 staging/dist/isee.adapters に生成されます。導入するときは、このファイルを管理者に渡してください。
アダプタの導入
アダプタを導入するには、管理者が次の手順を実行します。
手順 1 Service Link のカスタム アダプタ パッケージを取得します。これは、zip ファイル形式でなければなりません。
手順 2 一時ディレクトリ（c:\temp\adapter など）にアダプタを解凍します。このディレクトリを、今後 <AH> と呼びます。
手順 3 展開された「ISEE.war/WEB-INF/lib」ディレクトリに <AH>/adapters/<ADAPTER_NAME>.jar をコピーします。
手順 4 展開された「ISEE.war/WEB-INF/lib」ディレクトリに <AH>/lib/* ファイル（存在する場合）をコピーします。
手順 5 展開された「ISEE.war/WEB-INF/classes」ディレクトリに <AH>/config/* ファイル（存在する場合）をコピーします。
手順 6 展開された「ISEE.war/WEB-INF/classes」ディレクトリに <AH>/udk/* ファイル（存在する場合）をコピーします。
手順 7 カスタム アダプタが Adapter Development Kit を使用して内部的に作成されていない場合は、「<ServicePortal_Software_Dir>/adk」フォルダから adk.zip を入手します。ここで、<ServicePortal_Software_Dir> はサービス カタログ（Service Catalog）アプリケーションの解凍されたソフトウェア イメージです。adk.zip を c:\adk（Windows の場合）または /opt/adk（UNIX/Linux の場合）に解凍します。このディレクトリを、今後 <ADK> と呼びます。
手順 8 JAVA_HOME 環境変数が環境にまだ設定されていない場合は、これを設定します。
手順 9 コマンド ウィンドウを開き、<ADK>/lib フォルダにディレクトリを変更します。環境に応じて adapter_dbinstaller.sh または adapter_dbinstaller.cmd を実行します。--help または -? をアダプタ インストーラの引数として使用し、必要な入力引数のリストを表示します。Adapter Deployment Descriptor ファイルの指定を求められたら、<AH>/deploy ディレクトリの下に xml ファイル名をフル パスで入力します（/opt/<AH>/deploy/custom_adapter.xml など）。
手順 10 手順 6 でインストールされた各 udk ファイルについて、integrationserver.properties ファイル内の「UDConfig」プロパティにファイル名を追加します。UDConfig プロパティはすべての udconfig ファイルのカンマ区切りリストです。アダプタの udconfig ファイルをこのリストに追加します。
手順 11 Service Catalog および Service Link サーバを起動します。新しいアダプタがあることを確認します。
アダプタの実装について
アダプタは Service Link が外部システム（通常は サードパーティ システム と呼ばれます）に接続する手段です。アダプタは、3 つの部分で構成されます。
- 着信部分。 着信アダプタ と呼ばれます。
- 発信部分。 発信アダプタ と呼ばれます。
- エラーハンドラ
着信アダプタは、Service Catalog への着信通信を管理します。これは、システムに届く XML メッセージを処理します。受信アダプタには、ポーラーとリスナーの 2 種類があります。ポーラーは定期的に起動して、着信メッセージを探すスレッドです。これに対し、リスナーは待機し、外部イベントによって起動されます。ポーラーの例としては、メッセージを定期的にチェックする必要がある受信ファイル アダプタがあります。リスナーの例としては、HTTP XML イベントがポストされるまで待機する HTTP アダプタがあります。
発信アダプタは Service Catalog から発信される XML メッセージを管理します。発信アダプタのタイプは 1 つだけです。
エージェントは論理要素であり、これによりサービス設計者は、複雑なアダプタおよび接続プロパティをすべて把握する必要がなくなります。また、エージェントは着信アダプタと発信アダプタを定義します。着信アダプタは任意選択で、「自動完了（Auto complete）」と指定できます。「自動完了（Auto complete）」はワークフローの進行にサードパーティ システムからの応答を必要としないモードで、ほとんどの場合、電子メール ベース システムのような、信頼できない、または一度確立したら後は調整されないプロトコルと関連づけられます。管理者は、サービス設計者が使用できるようにエージェントおよびエージェントとアダプタとの関連付けを設定します。
また、メッセージがサードパーティ システムに送られる前、またはサードパーティ システムから受信され、Service Link に配信された後で、XML 変換をメッセージに適用できます。
メッセージ システムは nsXML と呼ばれる一般的な XML 方言を使用します。これは、Service Link が処理または作成できる有効な XML を定義するスキーマです。nsXML は、現在 6 つの操作で構成されています。
- task-started：発信
- task-cancelled：発信
- take-action：着信
- send-parameters：着信
- add-comment：着信
発信の場合、Service Link はこれらの操作を宛先に変換できます。同じことが着信メッセージでも行われ、XSL 変換によって外部形式を nsXML の方言に変換できます。
nsXML 操作の詳細については、通信メッセージのコンテンツと構造の理解を参照してください。
アダプタの種類
アダプタには次の 2 つのタイプがあります。
転送アダプタは HTTP、ファイル、JMS、または独自のネットワーク ソケット実装など、特定の転送に固有のものです。
アプリケーション アダプタには転送要素がありますが、Remedy や Siebel などの特定のサードパーティ アプリケーションを使用したほうがよく理解できます。多くの場合、jar によりネイティブ API が提供されます。このバージョンの Service Link では、転送アダプタを拡張してアプリケーション アダプタを作成することはまだ不可能です。
エージェントは着信メッセージと発信メッセージに異なるアダプタを使用することができます。
アダプタのコンポーネント
java コードの他には、次のものでアダプタは構成されています。
- Jar ライブラリ（Remedy java API など）
- 静的コンフィギュレーション ファイル。一度導入されたテキスト ファイルの変更は推奨されません。
- 展開記述子。アダプタを記述する XML ファイル。
接続プロパティ
アダプタは、Service Link モジュールが管理者に公開している接続プロパティを、サードパーティ システムに接続するために公開することができます。これらは XML 展開記述子内に記述されており、その値は java コードによって取得し、完成度の高い API に渡すことができます。
例：ファイル アダプタの実装
ここでは、簡単なアダプタを実装する方法を示します。サンプル アダプタは、外部環境との通信を行うファイル アダプタです。
この単純なファイル アダプタには次のものが含まれています。
- ファイルを作成する発信アダプタ。ファイル名はアダプタのプロパティで指定されます。
- ファイルを読み取る着信アダプタ。ファイル名はアダプタのプロパティで指定されます。
- 単純な例外ハンドラ。
ディレクトリ構造の作成
最初に、アダプタのディレクトリ構造を作成します。ADK ディレクトリ構造内に、 simple という名前のディレクトリを作成し、その下に次のディレクトリ構造を作成します。
図 6-1 Directory Structure
src の下が、java パッケージ com.newscale.is.adapter.filetest を表すソース パッケージになっていることに注目してください。他のパッケージも使用できますが、この例ではこれを使用します。
発信アダプタ クラスの作成
2 番目に、発信アダプタ クラスを作成します。名前は FileOutboundAdapter で、このクラス ファイルは、手順 1 で説明したパッケージに配置する必要があります。その枠組みを次に示します（メソッドの実装は含まれていません）。
import com.newscale.is.adk.AdapterContext;
import com.newscale.is.adk.base.OutboundAdapter;
import com.newscale.is.adk.exceptions.AdapterException;
public class FileOutboundAdapter extends OutboundAdapter {
public FileOutboundAdapter (AdapterContext context) {
public void initiate (AdapterContext context) throws AdapterException {
public void processMessage (String message, String channelId)throws AdapterException {
public void terminate () throws AdapterException {
public void commit() throws AdapterException {
public void rollback() throws AdapterException {
発信アダプタを作成するには、上記のようにクラス com.newscale.is.adk.base.OutboundAdapter をこのクラスで拡張する必要があります。
パラメータとして com.newscale.is.adk.AdapterContext を受け取るコンストラクタを実装します。このコンストラクタの実装に関して推奨される方法についても、上に示しています（スーパー コンストラクタを呼び出しています）。
上記のように initiate メソッドを実装します。このメソッドは、アダプタを使用するエージェントが起動されると呼び出されます。このメソッドが空の場合は省略可能です。
processMessage メソッドを実装します。このメソッドは、メッセージの送信準備が完了したときに呼び出されます。トランスフォーマがエージェントで指定されている場合、そのトランスフォーマによってメッセージが変換されています。
terminate メソッドを実装します。エージェントの停止時にこのメソッドを呼び出します。このメソッドが空の場合は省略可能です。
commit メソッドを実装します。エージェントがトランザクションを完了しようとしているときに、このメソッドを呼び出します。このメソッドが空の場合は省略可能です。このメソッドを使用すると、トランザクションを processMessage で開始し、後で完了できます。
rollback メソッドを実装します。このメソッドは、エージェントがトランザクションをロールバックしようとしているときに呼び出されます。このメソッドを空のままにする場合は省略可能です。このメソッドを使用すると、トランザクションを processMessage で開始し、後で再呼び出しできます。
トランザクション サポートの詳細については、トランザクション通知の設定を参照してください。
この例では、ファイル発信クラスは xml コンテンツを持つファイルを書き込みます。このために、ファイルが保存されファイル名を保持する変数を最初に設定します。これには、エージェントのプロパティを使用します。
public void initiate (AdapterContext context)
throws AdapterException {
Properties properties = context.getProperties();
this.path = properties.getProperty("OB_FILE_DIR") + "/" +
properties.getProperty("OB_FILE_NAME");
文字列が受信される場合、それをファイルに書き込むことは自明です。
public void processMessage (String message, String channelId)
throws AdapterException {
Writer w = new FileWriter(path);
throw new AdapterException(1, "Problem while writing to a file: " +
もちろん、このコードは説明のために大幅に簡素化しています。
ポーラー着信アダプタ クラスの作成
着信アダプタの枠組みは次のようになります。
public class FileInboundAdapter extends InboundAdapter {
public FileInboundAdapter (AdapterContext context) {
public void initiate (AdapterContext context) throws AdapterException {
public String receiveMessage () throws AdapterException {
public void terminate () throws AdapterException {
throws AdapterException {
throws AdapterException {
メソッドのセマンティクスは発信アダプタのものとほとんど同じです。唯一の例外は receiveMessage メソッドです。 receiveMessage メソッドは、ポーラー アダプタの場合は定期的に呼び出されます。データが検出されると、このメソッドは有効な xml をサードパーティ形式で返します。データが検出されなかった場合は、ヌルが返されます。着信アダプタのコードは次のとおりです（発信アダプタと同様、正しいパラメータを使用して初期化が行われます）。
public void initiate (AdapterContext context)
throws AdapterException {
Properties properties = context.getProperties();
this.path = properties.getProperty("IB_FILE_DIR") + "/" +
properties.getProperty("IB_FILE_NAME");
ファイルの処理は次のように行われます。
public String receiveMessage () throws AdapterException {
String receivedMessage = "";
StringBuffer buffer = new StringBuffer();
FileInputStream fis = new FileInputStream(path);
InputStreamReader isr = new InputStreamReader(fis, "UTF8");
Reader in = new BufferedReader(isr);
while ((ch = in.read()) > -1) {
buffer.append((char) ch);
String requestString = buffer.toString();
boolean success = (new File(path)).delete();
リスナー着信アダプタの作成
リスナー アダプタは、Ad-Hoc プロセスを利用して作成されます。着信アダプタ クラスと、servlet のような実際のレシーバ クラスという 2 つのクラスが動作します。レシーバ クラスは、チャネル ID を取得する必要があります。レシーバ クラスは、次のようにして InboundAdapter クラスを発見します。
ChannelInfoVO chVo = AgentDAO.getInstance().getChannelInfo(channelId);
Adapter adapter =
AgentManager.getInstance().getAdapter(chVo.getAgentId());
((InboundAdapter).receiverProcess(xml);
着信アダプタには、メッセージにより呼び出す必要がある receiverProcess メソッドか、または、 toString() メソッドがメッセージのテキストを返すオブジェクトがあります。サンプルには、リスナー着信アダプタは用意されていません。
例外ハンドラの実装
2 つのアダプタが完成したら、例外ハンドラを実装する必要があります。ここでは非常に単純なクラスを使用しているため、必要な処理はエラーの出力のみです。完全なクラスを以下に示します。
public class FileExceptionHandler implements ITransportExceptionHandler {
public FileExceptionHandler () {
public void handleException (Map props, String message) {
System.out.println("Outbound Message Failed to deliver: " + message);
トランザクション通知の設定
アダプタにはトランザクション サポートが提供されているため、アダプタのトランザクションを取り消す前にはエージェントへの通知が行われます。この目的のために、メソッド commit および rollback が追加されています。
（注） システムでトランザクションのコミットまたはロールバックを実行中に、これらのメソッドに論理コードを追加すべきではありません。これらのメソッドでロールバックまたはコミットするのは、自身のリソースのみにする必要があります。
次の一般的な手法をアダプタで使用すると、コミットまたはロールバックされたリソースをトラッキングすることができます。
静的マップを作成します。処理メソッド（processMessage または receiveMessage）が呼び出されると、そのメソッドは次のものを追加できます。
private static Map resources = new HashMap();
public void processMessage (String message, String channelId)
throws AdapterException {
Connection con = … // obtain a connection to external resource
Map.put(Thread.getCurrentThread(), con);
public void commit() throws AdapterException {
con = (Connection) map.get(Thread.getCurrentThread());
map.remove(Thread.getCurrentThread());
adapter.xml 記述子について
アダプタ記述子には、アダプタの導入とプロパティに関する情報が格納されます。
アダプタのスキーマ
アダプタのスキーマを次に示します。
図 6-2 アダプタのスキーマ
「adapter」要素のフィールドの説明
name ：アダプタの名前
description ：アダプタの説明
adapter-flow ：
有効な値は次のとおりです。
inbound-model ：
有効な値は次のとおりです。
- 「listener」
- 「poller」
- 「extendedpoller」
inbound-class ：着信アダプタの絶対クラス名
outbound-class :発信アダプタの絶対クラス名
exception-class ：このアダプタの例外ハンドラの絶対クラス名
poll-interval ：ミリ秒単位のポール間隔（「poller」タイプのアダプタに適用される）
max-retry ：メッセージが失敗した場合に行われる再試行の最大回数
retry-interval ：再試行間隔（ミリ秒）
「property」（アダプタ プロパティ）要素のフィールドの説明。
name ：アダプタ プロパティの名前
default-value ：プロパティのデフォルト値
is-required ：必須プロパティとオプション プロパティのいずれであるか。有効な値は「true」または「false」
property-type ：プロパティの種類。現在のところ、有効な値は「string」です。
property-presentation ：有効な値は「text」および「password」
adapter-flow ：
有効な値は次のとおりです。
Adapter.xml の例
<?xml version="1.0" encoding="UTF-8"?>
<name>InboundFinalResolution</name>
<default-value>Preserve</default-value>
<is-required>true</is-required>
<adapter-flow>inbound</adapter-flow>
<property-type>string </property-type>
<property-presentation>text</property- presentation>
<name>InboundFileLocation</name>
<default-value>C://SL2//InboundFiles</default-value>
<is-required>true</is-required>
<adapter-flow>inbound</adapter-flow>
<property-type>string </property-type>
<property-presentation>text</property- presentation>
<default-value>Preserve</default-value>
<is-required>true</is-required>
<adapter-flow>inbound</adapter-flow>
<property-type>string </property-type>
<property-presentation>text</property- presentation>
<name>InboundBackupLocation</name>
<default-value>c://SL2//InboundBackup</default-value>
<is-required>true</is-required>
<adapter-flow>inbound</adapter-flow>
<property-type>string </property-type>
<property-presentation>text</property- presentation>
<name>BackupSuffix</name>
<default-value>.bak</default-value>
<is-required>true</is-required>
<adapter-flow>inbound</adapter-flow>
<property-type>string </property-type>
<property-presentation>text</property- presentation>
<name>FileNameDateFormat</name>
<default-value>.yyyyMMddHHmmssSSS</default-value>
<is-required>true</is-required>
<adapter-flow>inbound</adapter-flow>
<property-type>string </property-type>
<property-presentation>text</property- presentation>
<name>InboundTempLocation</name>
<default-value>C://SL2//InboundTemp</default-value>
<is-required>true</is-required>
<adapter-flow>inbound</adapter-flow>
<property-type>string </property-type>
<property-presentation>text</property- presentation>
<name>OutboundConflictResolution</name>
<default-value>Rename</default-value>
<is-required>true</is-required>
<adapter-flow>outbound</adapter-flow>
<property-type>string </property-type>
<property-presentation>text</property- presentation>
<name>OutboundFileLocation</name>
<default-value>C://SL2//InboundFiles</default-value>
<is-required>true</is-required>
<adapter-flow>outbound</adapter-flow>
<property-type>string </property-type>
<property-presentation>text</property- presentation>
<name>OutboundBackupLocation</name>
<default-value>c://SL2//InboundBackup</default-value>
<is-required>true</is-required>
<adapter-flow>outbound</adapter-flow>
<property-type>string </property-type>
<property-presentation>text</property- presentation>
<name>OutboundTempLocation</name>
<default-value>C://SL2//InboundTemp</default-value>
<is-required>true</is-required>
<adapter-flow>outbound</adapter-flow>
<property-type>string </property-type>
<property-presentation>text</property- presentation>
<name>File Adapter</name>
<description>Read/write the external data from/to external file system</description>
<adapter-flow>inbound</adapter-flow>
<inbound-model>poller</inbound-model>
<inbound-class>com.newscale.is.adapter.file.FileInboundAdapter</inbound-class>
<outbound-class>com.newscale.is.adapter.file.FileOutboundAdapter</outbound-class>
<exception-class>com.newscale.is.adapter.file.FileExceptionHandler</exception-class>
<poll-interval>10000</poll-interval>
<retry-interval>0</retry-interval>
通信メッセージのコンテンツと構造の理解
ここでは、通信メッセージの内容と構造について詳しく説明します。メッセージの内容は、Service Catalog とサードパーティ システムの間で、HTTP、SOAP、JMS などの多様なキャリア プロトコルによって送信される XML 文書内にカプセル化されます。メッセージの構造およびサブ構造を理解しやすいよう、図に示します。
メッセージ（Message）
図 6-3 メッセージ（Message）
発信文書のトップ レベル要素 message には、「task-started」または「task-canceled」要素が格納されます。着信文書のトップ レベル要素 message には、「add-comments」、「send-parameters」、または「take-action」要素が 1 つ以上格納されます。message タグには、channel-id という文字列タイプの必須属性があります。これは、作成された発信メッセージに対して Service Link が生成する一意の文字列値です。サード パーティ システムは、メッセージに対応する channel-id で応答する必要があります。この ID は、サービス カタログ（Service Catalog）とサード パーティ システムの両方で引き継がれる必要があります。
Task Started または Task Cancelled
図 6-4 Task Started または Task Cancelled
Task started は、サードパーティ システムで外部アクティビティを開始します。この操作に関する設計上のポイントは、サードパーティ システムでタスクを実行するために必要となる可能性がある情報をすべて組み込むことです。この要素には、タスクおよびそのタスクが属している要求に関する、必要な詳細情報がすべて保持されます。また、オプションのエージェント パラメータも 1 つ以上含めることができます。context 要素は、サービス配信計画のコンテキスト内のタスクについて記述したものです。このノードに、要求レベルの確認および許可に関する値は格納されません。
タスク
図 6-5 タスク
表 6-4 タスク要素と説明
|
|
|
actual-duration |
タスクは実行中になったばかりであるため、空です。 |
calendar-entries |
サービスを要求した個人のカレンダ エントリ。 |
check-lists |
タスクのチェック リスト。 |
completed-date |
タスクはまだ完了していないため、空です。 |
context-id |
タスクが開始されたコンテキスト オブジェクトのオブジェクト ID。 |
context-type |
オブジェクトのコンテキスト（例：要求エントリ）。 |
due-date |
タスクの期日。 |
実行 |
予想されるタスクの時間単位の工数（1 人でタスクを完了するために必要な作業時間の予想）。 |
estimated-date |
予測されるタスクの完了日時。 |
expected-duration |
予想されるタスクの時間単位の所要期間（タスクの開始から完了までに要する作業時間の予想）。 |
flag-id |
UI のカラー インジケータ。 |
is-sharable |
タスクが共有可能かどうかを示すブール値。 |
is-shared |
タスクが共有されているかどうかを示すブール値。 |
next-action-id |
タスクに関して次に実行可能なアクションは何か。 |
performer |
タスクの実行者。performer 要素には、関連付けられた個人オブジェクトがあります。 |
performer-actual-duration |
タスクはまだ完了されていないため、空です。 |
performer-role |
実行者が果たしている処理ロールは何か。 |
[プライオリティ（priority）] |
タスクの優先順位：1、2、または 3（それぞれ高、中、または低を表す）。 |
キュー |
タスクが割り当てられているキューの説明。 |
scheduled-start-date |
タスクの開始が予定された日付。 |
start-date |
タスクが開始された日付。 |
state-id |
タスクの状態。 |
subject |
タスクの件名。件名は、サービス定義で変更されます。要求エントリでは変更されません。 |
スーパーバイザ |
タスクの上司。supervisor 要素には、関連付けられた個人オブジェクトがあります。 |
supervisor-role |
上司が果たしている処理ロール。 |
task-id |
このタスク インスタンスを一意に識別するために使用される整数。要求エントリのタスクごとに新しい番号が生成されます。 |
待機中 |
サブタスクおよびサードパーティ システムを含む、このタスクの依存関係を表すインジケータ。 |
要求
図 6-6 要求
requisition 要素は、すべての要求と要求エントリ データをカプセル化したものであり、外部アクティビティを実行するときに、統合の目的でこのデータを使用できます。
表 6-5 要求要素の説明表
|
|
|
サービス |
要求されるサービス数（または要求エントリ数）。 |
actual-cost |
要求の実際のコスト。 |
actual-duration |
要求の実際の所要期間。 |
closed-on |
要求はまだ完了していないため、空です。 |
コメント |
要求に関するコメント。 |
cost-center-code |
未使用。 |
インタビューの |
要求が注文された目的となっている個人。個人のオブジェクト データが保持されます。 |
due-on |
要求の配信期限を表す日時。 |
expected-cost |
予想される要求のコスト。 |
expected-duration |
要求全体の処理にかかると予想される所要期間（時間単位）。 |
外部 |
要求が外部システムから開始されたかどうかを示すブール値。 |
initiator |
この要求をオーダーした個人。個人のオブジェクト データが保持されます。 |
呼び出し |
RAPI（要求 API）からセットアップされた属性。 |
organizational-unit |
要求者（発信者）の組織単位。 |
requisition-entry |
要求エントリのデータ。 |
requisition-id |
送信された要求の整数 ID。要求を手動で送信した後に My Services および Service Manager に表示される ID と同じです。 |
requisition-step |
要求の承認または配信のステップとステータス。 |
started-on |
要求が開始された日付。 |
status |
要求の現在の状態。外部アクティビティの実行中は Ongoing となります。 |
要求エントリ
図 6-7 要求エントリ（Requisition Entry）
このタグは、1 つの要求エントリのデータをすべてカプセル化したものであり、統合のために使用できます。
表 6-6 要求エントリ要素の説明表
|
|
|
closed-date |
要求エントリのステータスが ongoing から completed に変化した日時。タスクが ongoing である間は要求がクローズされないため、空になります。 |
data-values |
要求エントリのデータ値。 |
due-date |
要求が終了する予定の日付。 |
item-number |
要求内の要求エントリの項目番号。 |
price-per-unit |
要求されたサービスの単価。 |
priced |
要求の価格が設定されている場合は true、設定されていない場合は false。 |
quantity |
注文された数量。 |
rejected |
要求エントリが承認されたか、拒否されたかを示します。 |
rejected-date |
拒否された場合は、その日付。 |
rejector |
要求を拒否した個人を示します。 |
requisition-entry-id |
エントリ ID。 |
revision-number |
リビジョンが作成されている場合は、そのリビジョン番号を示します。 |
service |
要求エントリが属しているサービスに関連する要素。 |
start-after |
遅れて開始される日付。 |
start-date |
要求エントリが開始された日付。 |
start-mode |
要求エントリがすぐに開始されるか、遅延されるかを指定します。 |
status |
要求エントリのステータス：closed または ongoing。 |
データ値
図 6-8 データ値
data-values 要素は、ディクショナリ データで構成されるデータ値を 1 つ以上持つことができます。data-value の name は「Dictionaryname.FieldName」を指し、value はサービスの注文時にユーザが入力した値です。その値が複数選択ドロップダウン リストになっている場合は、1 つの data-value 要素が複数の値を持つことができます。
サービス
図 6-9 サービス
表 6-7 サービス要素の説明表
|
|
|
ディクショナリ |
service 要素は、ゼロ個以上のディクショナリを持つことができます。 |
estimated-cost |
予測されるサービスのコスト。 |
form |
サービス フォームのすべてのフィールド要素を保持する要素。 |
名前 |
サービスの名前。 |
パラメータ |
このサービスに定義されているパラメータ。 |
pricing-schema |
サービスが、入札で価格設定を行うタスクであるか、固定価格であるかを指定します。 |
quantity |
注文された数量。 |
service-id |
Service Catalog のサービスの ID。 |
version |
サービスの最終更新バージョン番号。 |
standard-duration |
サービスの標準的な所要期間。 |
辞書（Dictionary）
図 6-10 ディクショナリ
表 6-8 ディクショナリ要素の説明表
|
|
|
caption |
ディクショナリ内のキャプション データが格納された文字列値。 |
データ |
ディクショナリ内のデータ要素。データ要素には、データ要素の名前、最大長、データ型、およびその他のメタデータの値が保持されます。 |
dictionary-id |
Service Catalog 内のディクショナリのディクショナリ ID。 |
dictionary-template-type-id |
ディクショナリの作成に使用されたテンプレート（たとえば、個人ベースのディクショナリの場合は 2）。 |
classification-id |
ディクショナリの分類（サービス項目ディクショナリの場合のみ）。 |
mdr-data-type-id |
ディクショナリのサービス項目タイプ（サービス項目ディクショナリの場合のみ）。 |
display-order |
ディクショナリの表示順序が入った整数値。 |
is-external |
ディクショナリが内部 Service Catalog ディクショナリであるか、外部ディクショナリであるかを示すブール値。 |
is-reportable |
ディクショナリが、Advanced Reporting モジュールの Ad-Hoc レポート機能での使用に関して、レポート可能としてマークされているかどうかを示すブール値。 |
is-shared |
ディクショナリが共有ディクショナリであるかどうかを示すブール値。 |
is-template |
ディクショナリがテンプレートであるかどうかを示すブール値。この値は必ず false になります。 |
logic-name |
ディクショナリの内部名（予約ディクショナリの場合のみ）。 |
名前 |
ディクショナリの名前。 |
フォーム
図 6-11 フォーム（Form）
表 6-9 フォーム要素の説明表
|
|
|
フィールド |
フィールドは、要求フォームの内部に 1 つまたは複数の field 要素を持ちます。 advanced-prompt：リッチ HTML プロンプト。 data：データ型、名前、長さなどのフィールドのデータが保持されます。 dictionary-display-order：dictionary-display-order の値は、フィールドに関連付けられた DataElement に関連付けられている Dictionary の DefObjectDictionaries.DisplayOrder の値です。 display-order： display-order の値は、フィールドの DefObjectDataHTML.DisplayOrder の値です。 field-id：Service Catalog データベース内でのフィールド ID。 input-type：フィールドの入力の種類（例：text、option など）。 label：フィールドに指定されているラベル。 mandatory：フィールドのデータは、サービスで必須です。 max-length：フィールドに指定されている最大長。 max-value：数値の場合は範囲が指定されます。 min-value multi-select：入力の種類が複数選択ボックスかどうか。 options：このデータ フィールドに使用可能なオプション リスト。 permission： validated：検証が必要かどうか。 |
user-id |
|
エージェント パラメータ
図 6-12 エージェント パラメータ
エージェント パラメータは、エージェントに対して指定されている外部パラメータを表します。これには multi-valued というブール属性があり、ユーザが複数の値を選択できるパラメータかどうかに基づいて true または false のいずれかになります。name はエージェント パラメータの名前を表し、value はその値を表します。
フィードバック