ASTERIA Warp FAQ

フローの実行とスケジュール

Q1SingleScheduleコンポーネントで登録したスケジュールはどこで確認できますか？

A

スケジュールコンポーネント（SingleSchedule, IntervalSchedule, RegularSchedule）で設定したスケジュールはScheduleListコンポーネントの出力結果で確認できます。 フローサービス管理コンソール(FSMC)やフローデザイナーの実行設定画面では表示されません。 また、ScheduleListコンポーネントの出力結果には実行設定で設定したスケジュールは含まれません。

Q2デザイナーのURL実行設定画面で「ブラウザから実行」ボタンがグレーアウトしてクリックできません

A

フローサービス管理コンソール(FSMC)の「設定」-「サービス」-「フロー」の「通信」画面でHTTPリスナーが無効になっているときには、フローデザイナーのURL実行設定画面で「ブラウザから実行」ボタンはグレーアウトされ、クリックすることはできません。 FSMCからHTTPリスナーの状態を確認してください。

Q3「HTTPコンテキストパスが設定されていません」というメッセージが出力されてURLトリガーを設定できません

A

URLトリガーを作成するユーザーのコンテキストパスが設定されていないときに出力されるメッセージです。

管理コンソール(FSMC)の「ツール」-「アカウント」画面のコンテキスト設定で「HTTPユーザーとして使用」が「ON」に設定されているか確認してください。

Q4URL実行設定の「公開するプロトコル」のサーバーアドレスを変更することはできますか

A

フローデザイナーの実行設定画面で確認できる「公開するプロトコル」は下記の文字列の組み合わせで表示されサーバーアドレス含めこの値を直接編集して変更することはできません。

http(s)://<サーバーアドレス>:<ポート番号（デフォルトでは21380）>/<ユーザーコンテキスト><相対パス>

「公開するプロトコル」で表示されるサーバーアドレスは実行設定画面を開いているフローデザイナーからサーバーへ接続している情報をもとに表示されます。

例：「サーバー名」にlocalhostとして接続しているときに「公開するプロトコル」で表示される文字列

http://localhost:21380/guest/Project1/Flow1

フローの実行URLとして使用するサーバーアドレスのホスト名やIPアドレスは「公開するプロトコル」で表示される文字列と一致していなくても、httpリクエスト送信元のクライアントからASTERIA Warpサーバーへ接続が確立できる値であれば問題ありません。

Q5URLトリガーで対応しているメソッドについて教えてください

A

GET、POST、PUT、DELETEメソッドのみ、URLトリガーでフローを実行することができます。

HEADメソッドには対応していません。

Q6URL起動のフローを実行するとステータスコード202が返ってきます

A

URL起動のフローを実行した場合、起動したフローの「タイムアウト」プロパティに指定された秒数を超えてもフローが終わらないときにステータスコード「202 Accepted」がHTTPクライアントに通知されます。これを防ぐには「タイムアウト」プロパティに長い時間を設定します。

フローのプロパティは、フローデザイナーのツリーペインでフローをクリックしたときにインスペクタに表示されます。値を変更した場合はプロジェクトを保存します。

このようにタイムアウトが発生した場合も、フローサービス上ではフローは中断されずに処理を継続するのでご注意ください。 フローがタイムアウトしたときの動作については、FAQ「フローがタイムアウトしたときの動作について教えてください」を参照してください。

Q7URLトリガーでPOSTメソッド以外は受け付けないようにするにはどうすればいいですか？

A

URLトリガーで起動されたフローの中でシステム変数「HTTPリクエストのメソッド」が「POST」かどうか判定し、「POST」以外であればフローを終了するような処理にすることで、POSTメソッド以外は受け付けないようにすることができます。

Q8フローでHTTPクライアントの情報を取得するにはどうすればよいですか？

A

URLトリガーで実行するフローでは、システム変数「呼び出し元ホスト名」などでHTTPリクエストの情報を取得することができます。

システム変数は、フローデザイナーのメニューから「編集」-「システム変数」をクリックして一覧から使いたいシステム変数をチェックすると、マッパー画面の左側のツリーに表示されるようになります。

システム変数については「フローサービスマニュアル」の「はじめに」-「フローの構成要素」-「変数」-「システム変数」を参照してください。

📝 NOTE
URLトリガーは、ASTERIA Warp Core/Core+ エディションではお使いいただけません。

ASTERIA Warp エディション機能対応表

Q9フローがHTTPリクエストから実行されたときにCookieを利用することはできますか？

A

HttpStartコンポーネントの「Cookie」プロパティにCookieの名前を指定すると、フローがHTTPリクエストから実行されたときに値が設定されますので、それを参照するようにフローを設計して利用することができます。

フローでCookieを設定するには、HttpEndコンポーネントの「Cookie」プロパティにCookieの名前と設定する値を指定します。

詳しくは各コンポーネントヘルプを参照してください。

📝 NOTE
HttpStartコンポーネント・HttpEndコンポーネントは、ASTERIA Warp Core/Core+ エディションではお使いいただけません。

ASTERIA Warp コンポーネント比較表

Q10特定の日だけ起動するスケジュールを設定する方法はありますか？

A

不規則な日程に対してフローを実行したい場合、以下のように設定してください。

  1. カレンダーを以下の画像のようにフローの実行日以外を全て休日にする
  2. 毎日実行するスケジュールを作成し、「休日設定」を1で作成したカレンダーを選択し「休日時の処理」を実行しないに選択する

同様に特定の日だけフローを実行させたくない場合も、同様に実行したくない日を休日に設定してください。

管理コンソールのカレンダー画面

参考

Q11終了日時が指定されたスケジュール実行設定はいつ削除されますか

A

終了日時が指定されたスケジュール実行設定は、最後のフロー実行時に削除されます。

Q12スケジュールトリガーの編集で設定当日を休日にしたとき次回実行日時がずれる

A

Warpバージョン2312まではスケジュールトリガーで「休日時の処理」を「実行しない」に設定し、カレンダーの休日設定を編集し、当日を休日に変更した場合、既存の次回実行日時の日付部分のみ変更され、時刻部分は変更されません。

編集作業を行った当日を休日にしないように運用するか、変更した場合は、既存のスケジュールを確認し、必要に応じて再設定を行ってください。

例

8月15日の時点でのスケジュール実行設定が次の状態となっているとします。

  • スケジュールの種類：一定間隔
  • 実行間隔：１時間
  • 有効時間：08:00～17:00

  • 休日時の処理：実行しない

  • 8月15日 11:30に管理コンソールでカレンダーの休日設定を行い、当日（8月15日）を休日に変更する

  • カレンダー編集時点での当該次回実行日時が 8/15 12:00 となっているため、カレンダー更新後、次回実行日時は日付部分のみ更新され 8/16 12:00に設定される
  • そのため、このままでは 8/16 の 08:00 から 11:00 はスケジュールが実行されない
  • この場合、手動で当該スケジュールを編集・保存して、次回実行を 8/16 08:00 として再設定する必要がある

Q13スケジューラーが停止した状態のときに実行設定した時刻が過ぎたスケジュールはどうなりますか？

A

スケジュール実行設定の「停止中に実行時刻を経過した場合は再開時に実行する」チェックボックスの指定によって動作が変わります。

「停止中に実行時刻を経過した場合は再開時に実行する」チェックボックスをチェックした場合(初期設定)には、複数回実行時刻を過ぎていたとしてもスケジューラーの再開時に１回だけ実行されます。

例：チェックボックスをチェックした場合

  1. 4/1の11:00にフローサービスを起動し、毎日12:00実行のスケジュール実行設定を作成する。このとき、「停止中に実行時刻を経過した場合は再開時に実行する」チェックボックスをチェックしておく
  2. 4/1の12:00までにフローサービス管理コンソールでスケジューラーを停止する
  3. 4/3の13:00にフローサービス管理コンソールでスケジューラーを開始する（フローサービスは4/1から開始したまま）

この場合の動作は以下のようになります。

  1. 4/1の12:00にフローを実行するスケジュールがスケジューラーに登録される
  2. スケジューラーが停止されているため4/1の12:00になってもフローは実行されない
  3. 4/3の13:00にスケジューラーを開始したことで、フローはスケジューラーの開始直後に１度だけ実行される。この後、次回の実行時刻は4/4の12:00となる

「停止中に実行時刻を経過した場合は再開時に実行する」チェックボックスをチェックしなかった場合には、実行時刻が過ぎたスケジュールはスケジューラーの再開時に実行されません。

上記例のように実行設定した場合、再開後の最初の実行は4/4の12:00となります。

Q14ステータスが無効の間にスケジュールの実行時刻が過ぎた場合、ステータスを有効にしたときにフローが実行されますか？

A

スケジュール実行設定で、ステータスを無効にしていた間に実行時刻を過ぎた場合、もう一度ステータスを有効にしたときにフローが実行されるかどうかは、実行設定の「停止中に実行時刻を経過した場合は再開時に実行する」の設定により異なります。

設定をチェックした場合、無効の期間は停止中と同様に扱われ、ステータスを有効にしたときにフローが実行されます。チェックしていない場合は、ステータスを有効にしたあともフローは実行されません。

設定については、「フローサービスマニュアル」の「フローデザイナー」-「トリガー管理」-「実行設定」-「スケジュール起動の共通項目」を参照してください。

Q151つのスケジュール実行設定で複数のフローを実行することはできますか？

A

できません。 1つのスケジュール実行設定で処理フローとして指定できるフローは１つです。

スケジュール実行設定の設定手順については「フローをスケジュール登録して実行するには」という記事も参照してください。

Q16毎年1回フローを実行するスケジュールを設定することはできますか？

A

毎年１回、特定の日にフローを実行するといった年次処理の実行設定はありません。スケジュールの実行設定で「指定日時に実行」を使用して、必要な年数分の実行設定を登録してください。

Q17毎月実行するスケジュールで存在しない日を指定するとどうなりますか？

A

毎月実行するスケジュールで、例えば31日をチェックした場合に、31日がない2月などには実行されません。28、29、30、31をチェックしていた場合、2月28日に実行されたあとは3月28日に実行されます。閏年の場合は2月28日、2月29日の次に3月28日に実行されます。

Q18サーバーの時刻を戻した場合、スケジュール設定したフローは再実行されますか？

A

サーバーの時刻を戻した場合、次に実行される時刻は戻す前に計算されて保存されていますので、保存された時刻に実行されます。

例えば、8:00に実行されるフローがあった場合、8:30から同日の7:30に時刻を戻したとしても、次回に実行する時刻として翌日の8:00が設定されていますので翌日まで実行されません。

Q19フローデザイナーを使わずにスケジュールを登録することはできますか？

A

flow-ctrlのregist scheduleコマンドを利用することで、フローの実行をスケジュールに登録することができます。

コマンドの詳細はflow-ctrl コマンドリファレンス → regist scheduleを参照してください。

Q20フローで受信したメールを取り込んで処理したいときはどうすればよいですか？

A

受信メールを処理するのにはメール監視トリガーを利用するのが簡単です。

詳しくは「フローサービスマニュアル」の「はじめに」-「トリガーごとのフローの作成」-「メール監視起動のフロー」を参照ください。

Q21メール監視トリガーで起動するフローの動作について詳しく教えてください

A

メール監視トリガーで起動するフローは、指定したメールサーバーで指定したアカウントのメールボックスを監視し、メールを受信するとフローが起動されます。

📝 NOTE
メール監視トリガーは、ASTERIA Warp Core エディションではお使いいただけません。

ASTERIA Warp エディション機能対応表

メール監視トリガー設定画面

フローデザイナーの「実行設定」ダイアログボックスまたはトリガー管理の画面上部にあるメールのアイコンをクリックします。

メールを処理するフローの設定

実行設定では、以下の３つのフローを指定できます。

  • 本文処理フロー — メール本文または全体のMIMEを処理するフローを選択します。
  • 添付ファイル処理フロー — メールの添付ファイルを処理するフローを選択します。
  • エラー処理フロー — エラー発生時に実行するフローを選択します。

メール監視トリガーの動作概要

メール１件ごとに内部的に自動生成されたメール監視用のフローが起動され、このフローのサブフローとして実行設定で指定した「本文処理フロー」と「添付ファイル処理フロー」を実行するようになっています。本文処理フロー、添付ファイル処理フローのどちらかでエラーが発生してアボートした場合に「エラー処理フロー」が実行されます。

📝 NOTE
「本文処理フロー」、「添付ファイル処理」フローで、フロープロパティまたはコンポーネントプロパティの「エラー処理」プロパティでエラー時のフローを設定し、そのフローが正常終了する場合は実行設定で指定した「エラー処理フロー」は起動されません。

メール１件ごとにフローが起動されるようになっているため、１回のポーリングで複数メール受信した場合にいずれかのメール処理でエラーが発生してもすべてのメールが処理されます。実行設定の「メールの削除」項目で指定した削除対象にならなかったメールは、ユーザーホームディレクトリ内のフォルダにファイルとして保存されて最初の受信以降は受信しません。

メール監視トリガーの具体的な動作

メール監視トリガーでは、ユーザーのホームフォルダーに以下のフォルダが作成されます。

  • mailsフォルダ ：_mails/POP3/[メールコネクション名]/mails
  • errorsフォルダ：_mails/POP3/[メールコネクション名]/errors

次のような順序で処理が行われます。

  1. POPサーバーにあるメールを受信して、mailsフォルダ配下にMIMEをファイルとして保存する
  2. メールが既にerrorsフォルダに保存されている場合は何もしない
  3. mailsフォルダのファイルに対して実行設定で指定されたフローを順次実行する
  4. 削除条件を満たさなかった（実行設定に指定されていない）ファイルはerrorsフォルダに移動する
  5. mailsフォルダのファイルを全部処理するまで2、3の処理を繰り返す
  6. 4の終了時点でmailsフォルダにあるファイルは削除対象のメールとなる
  7. 再度POPサーバーに接続する
  8. mailsフォルダにあるメールをPOPサーバー上削除し、同時にmailsフォルダにあるファイルも削除する
  9. mailsフォルダにあるファイルがPOPサーバー上に存在しない場合はファイルを削除する

📝 NOTE
次回実行時にmailsフォルダにファイルが残っている場合は1よりも先に7、8の手順を実行する。

メール監視トリガーにおいてメールが削除される条件

実行設定の「メールの削除」項目の指定により、以下の条件で削除されます。

「正常終了時に削除」の場合

「本文処理フロー」、「添付ファイル処理フロー」の両方が正常終了した場合にのみ削除されます。

📝 NOTE
「エラー処理フロー」が実行された場合、「エラー処理フロー」が正常終了した場合に削除されます。 （Exceptionコンポーネントで異常終了した場合は削除されません。）

「戻り値が「」の場合削除」の場合

「本文処理フロー」、「添付ファイル処理フロー」の両方が同じ値を返した場合のみ削除されます。

📝 NOTE
「エラー処理フロー」が実行されて終了した場合、その戻り値は無視されるためメールは削除されません。

メール監視トリガーの設定方法については、「フローサービスマニュアル」の「フローデザイナー」-「トリガー管理」-「実行設定」-「メール監視」を参照してください。

Q22メール監視トリガーはIMAP4サーバーに対応していますか？

A

対応していません。

Q23メール監視トリガーで未読メールのみを取り込むことはできますか？

A

メール監視トリガーでは未読/既読の管理を行っていないので、POP3サーバーにあるメールはすべて処理の対象になります。

実行設定の「メールボックスの設定」の「メールの削除」で削除するように指定した場合、取り込んだメールはサーバーから削除されるので通常問題となることはありませんが、他のメールクライアントで既読になっていてサーバーに残してあるメールは処理されるので注意してください。 FAQ「メール監視トリガーで起動するフローの動作について詳しく教えてください」も併せて参照してください。

Q24メール監視トリガーでメールのヘッダー情報を取得するにはどうすればよいですか？

A

メールヘッダーの情報は本文処理フローや添付ファイル処理フローのフロー変数にヘッダーと同じ名前の変数を作成し、それを公開変数とすることで取得できるようになります。

本文処理フローや添付ファイル処理フローを作成するときは、「プロジェクトの作成」ダイアログボックスで、「フロー」タブの「メール本文処理」や「メール添付ファイル処理」をクリックして作るのが簡単です。詳しくは「フローサービスマニュアル」の「はじめに」-「トリガーごとのフローの作成」-「メール監視起動のフロー」を参照ください。

Q25メール監視トリガーの添付ファイル処理フローで添付ファイルを取得するにはどうすればよいですか？

A

メールの添付ファイルはStartコンポーネントのストリームとして取得できます。取得するファイルにあわせて適宜ストリーム型を指定してください。ただし、変換できない場合はエラーとなります。 添付ファイル処理フローを作成するときは、「プロジェクトの作成」ダイアログボックスで、「メール処理」を選択し、「メール処理の対象」ダイアログで「添付ファイル」にチェックをつけて作るのが簡単です。 詳しくは「フローサービスマニュアル」の「はじめに」-「トリガーごとのフローの作成」-「メール監視起動のフロー」を参照ください。

Q26メール監視トリガーの本文処理フローでメール本文を取得するにはどうすればよいですか？

A

メール本文はStartコンポーネントのTextストリームとして取得できます。

本文処理フローを作成するときは、「プロジェクトの作成」ダイアログボックスで、「フロー」タブの「メール本文処理」をクリックして作るのが簡単です。詳しくは「フローサービスマニュアル」の「はじめに」-「トリガーごとのフローの作成」-「メール監視起動のフロー」を参照ください。

Q27複数のメール監視トリガーで同一メールアドレスを監視することができますか

A

メール監視トリガーではPOP3コネクションを使用します。 POP3メールサーバは単一クライアントとのメールデータのやり取りを前提としているため、 同一メールアドレスに対して複数のメール監視トリガーを指定してメールを取得することはできません。

Q28メールに添付されたファイルのファイル名を取得するにはどうすればよいですか？

A

フローで、メールに添付されたファイルを処理するにはメール監視トリガーを利用するのが簡単です。

メール監視トリガーは、メールボックスを監視してメールを受信するとフローを起動する機能です。この実行設定では添付ファイル処理フローを指定することができます。

添付ファイル処理フローに指定したフローは１つのメールに添付されているファイルの数ごとに起動され、フロー変数「Attachement- Filename」にそのファイル名が設定されるのでそれを参照します。添付ファイル処理フローは、フローデザイナーの「プロジェクトの作成」ダイアログボックスで「メール添付ファイル処理」を選択して作成します。

メール監視トリガーの設定については「フローサービスマニュアル」の「フローデザイナー」-「トリガー管理」-「実行設定」-「メール監視」を参照してください。

メール監視トリガーから起動されるフローについては「フローサービスマニュアル」の「はじめに」-「トリガーごとのフローの作成」-「メール監視起動のフロー」を参照してください。

Q29ファイルをアップロードしたタイミングでフローを実行したいのですが？

A

ファイルをFTPサービスにアップロードしたタイミングでフローを実行したい時には、フローの実行設定でFTPを指定します。フローサービスに内蔵されたFTPサービスにファイルをアップロードすると、ファイルのアップロード完了後に設定されたFTPトリガーからフローが実行されます。

FTPトリガーについて詳しくは「フローサービスマニュアル」の「はじめに」-「トリガーごとのフローの作成」-「FTP起動のフロー」を参照してください。

Q30FTPサービスではAPPENDコマンドでのファイル送信時にファイルが存在しない場合はファイルを作成しますか？

A

新規にファイルを作成することはできません。「450 Requested file action not taken」というエラーになります。

Q31FTPトリガーでFTPユーザーと異なるユーザーのフローを実行したい場合はどうすればいいですか？

A

FTPトリガーは、FTPサービスにログインしたユーザーが所有するフローのみを起動できます。 ログインユーザーではないユーザーが所有するフローの起動は、FlowInvokerコンポーネントを使用することで実現できます。

使用例

  1. USER1で、メイン処理のフローを作成する
  2. USER2をFTPユーザーとし、FTPトリガーで起動するフローを作成してそのフローの中でUSER1が作成したメイン処理フローを呼び出す

USER1 - フロー作成ユーザー

  • フロー：ownertest.Flow1
  • フローのプロパティ設定
    • 実行を許可するユーザ：USER2

USER2 - FTPユーザー

  • フロー：ftptest.Flow1
  • Start ⇒ FlowInvoker ⇒ End　※シンプルなフロー構成にします
  • FlowInvokerコンポーネント設定
    • 実行するフロー：ownertest.Flow1
    • 実行するフローのオーナー：USER1

詳細については、FlowInvokerコンポーネントヘルプをご参照ください。

📝 NOTE
FlowInvokerコンポーネントは、ASTERIA Warp Core/Core+/Core++ エディションではお使いいただけません。

ASTERIA Warp コンポーネント比較表

Q32APPENDコマンドでのファイル転送でFTPトリガーに登録されたフローは起動されますか？

A

はい、APPEND(APPE)コマンドで追記する場合もファイル受信完了時にFTPトリガーでフローが起動されます。

Q33SOAPトリガーで起動したフローで添付ファイル付きのSOAPメッセージを受け取ることはできますか？

A

📝 NOTE
ASTERIA Warp 2412以降、SOAP機能は廃止されています。

SOAPトリガーでは添付ファイル付きのSOAPメッセージ(SOAP with attachments)に対応していません。

お使いのバージョンのフローサービスマニュアルの「はじめに」-「トリガーごとのフローの作成」-「SOAP起動のフロー」を参照してください。

URLトリガーで起動したフローでは、添付ファイル付きのSOAPメッセージを取得後にメッセージの解析をフロー内部で実装することで対応は可能です。

StartコンポーネントをMIMEストリームに、またEndResponseコンポーネントをXMLストリームとするフローを作成し、SOAPメッセージの送受信時において、SOAPエンコード/デコード等をフロー内で実装します。また、実行設定がURLタイプとなり、WSDLを自動生成できないためお客様側にてWSDLを作成する必要があります。

SOAPエンコード/デコードには、以下のコンポーネントを利用することで可能となります。

  • SOAPRPCEncoderコンポーネント
  • SOAPDocumentEncoderコンポーネント
  • SOAPDecoderコンポーネント

Q34ASTERIA WarpがSOAPサーバーになるときにSSLで通信したいのですが？

A

📝 NOTE
ASTERIA Warp 2412以降、SOAP機能は廃止されています。

ASTERIA WarpがSOAPサーバーになる場合、通常のURLトリガーでHTTPSサーバーになるときと同様の設定でSSL通信を行うことができます。

ただし、WSDLをASTERIA Warpで自動生成している場合、HTTPSには対応していませんので、生成したWSDLのsoap:address要素のlocation属性の値をHTTPS用のURLに変更する必要があります。

Q35実行設定をバージョン管理することはできますか？

A

実行設定の情報をそのままバージョン管理することはできませんが、プロジェクトを更新するたびに実行設定ファイルを自動的にエクスポートし、そのファイルをバージョン管理の対象にすることで擬似的にバージョン管理することができます。

手順は次のとおりです。

  1. 管理コンソールの「ツール」-「アカウント」画面の「その他」で「プロジェクト更新時にエクスポートファイルを作成する」をチェックする
  2. 指定したファイル名で実行設定の情報が更新のたびにエクスポートされる
  3. エクスポートされたファイルをバージョン管理機能でコミットする

このようにすると、開発機から本番機への移行時にバージョン管理機能を利用して配布することが簡単にできます。

その後、このファイルを使用して実行設定をインポートすれば移行も簡単になります。

Q36実行設定をエクスポート、インポートするときの注意点は？

A

フローデザイナーで実行設定をエクスポート、インポートするには、「実行設定」ダイアログボックスの画面上部にある「エクスポート」「インポート」アイコンをクリックしてファイルを指定します。

エクスポート

エクスポートでは、プロジェクトの登録情報と実行設定をファイルに出力します。

「エクスポート」ダイアログボックスの「プロジェクトのエクスポート」欄では、実行設定以外にプロジェクトの登録情報もエクスポートするかどうかを選択します。下部の実行設定一覧で、チェックボックスでチェックした実行設定がエクスポートの対象になります。

実行設定とプロジェクトの登録情報の両方をエクスポートしておくと、インポート時にエクスポートされたプロジェクトがコンパイルされるため、別途プロジェクトをコンパイルして登録する手順をすることなくすぐに実行できるようになります。プロジェクトの登録情報をエクスポートしない場合、実行設定をインポートする前にプロジェクトをコンパイルしておく必要があります。

インポート

インポートでは、指定したエクスポートファイルから実行設定を定義します。プロジェクトの登録情報がある場合はプロジェクトをコンパイルして登録します。プロジェクトファイルは、事前にインポートするユーザーのホームディレクトリに配置します。インポート先のユーザーは同じ名前である必要はありません。

インポートの「開く」ダイアログボックス

  • 接続先: エクスポートファイルの置き場所を選択します。
  • 更新オプション: すでにインポートした実行設定がある場合の動作を選択します。
  • 実行可能オプション: 実行設定のステータスをどのように設定するかを選択します。

実行設定が重複する場合

  • URLとSOAPの実行設定がすでにある実行設定と重複する場合、エラーが発生して登録されません。その他の実行設定のインポート処理は継続します。
  • スケジュールの実行設定がすでにある実行設定と重複する場合、追加登録されます。同一スケジュールIDの場合は上書きされます。

📝 NOTE
ASTERIA Warp 2412以降、SOAP機能は廃止されています。

flow-ctrlコマンドでのエクスポート、インポート

flow-ctrlのexport、importコマンドは上記と同じ動作です。ただし、exportコマンドでは特定の実行設定のみをエクスポートすることはできません。該当ユーザーのすべての実行設定とプロジェクトの登録情報がエクスポートされます。

Q37フローをデバッグモードで実行する方法を教えてください

A

デバッグモードで実行する方法は、実行手段ごとに以下の通りです。

フローデザイナーから実行する場合

フロー実行画面の右上にある「実行モード」を 「デバッグ」 に指定して実行します。

実行設定（トリガー実行）を使う場合

実行設定画面で「処理フローの設定 > 実行モード」を 「デバッグ」 に指定して登録します。 登録後、トリガーによる自動実行時もデバッグモードで実行されます。

flow-ctrl コマンドを使う場合

-mode オプションに debug を指定します。

exec Project1 Flow1 -mode:debug

flowthinclient を使う場合

コマンドラインから実行する場合（FlowExec）

-mode オプションに debug を指定します。

java -cp flowthinclient.jar com.infoteria.asteria.flowengine2.thinclient.app.FlowExec \
  -user:/guest -password:guest -project:Project1 -flow:Flow1 -mode:debug

Javaコードから実行する場合

setExecuteMode() メソッドに MODE_DEBUG を指定します。

FlowExecuteClient execClient;
FlowRequest request = new FlowRequest();
request.setUserName("/guest");
request.setProjectName("Project1");
request.setFlowName("Flow1");
request.setExecuteMode(MODE_DEBUG);
String requestId = execClient.post(request);

フローサービス API を使う場合

mode パラメーターに debug を指定してリクエストします。

http://{Hostname}:{Port}/api/flow/execute?project=Project1&flow=Flow1&mode=debug

⚠️ CAUTION
デバッグモードを有効にすると、ログ出力量の増加によりディスク容量の圧迫やパフォーマンス低下を招く可能性があります。ログ取得時は空き領域に十分注意したうえで、空き領域の枯渇が予想される場合は適切なタイミングで設定を元に戻してください。

Q38一定期間内に起動したフローの数を取得する方法はありますか？

A

フローデザイナーに同梱されているログビューアーで、フロー実行ログであるFlowService.logを解析してフローの実行回数を取得できます。

ログビューアーで解析したいFlowService.logを表示し、｢ツール｣メニューの｢FlowServiceログを解析｣を選択して画面を表示します。｢FlowServiceログを解析｣画面で、10分から１日単位のレポートでフローの実行回数を確認できます。 レポートは｢日時集計レポート｣、｢フロー集計レポート｣、｢フロー実行詳細｣があり、レポートをファイルに出力することもできます。詳しくはフローサービスマニュアルの「フローデザイナー」-「ログビューアー」-「ログの解析」を参照してください。

Q39リクエストIDの命名規則を教えてください

A

フローのリクエストIDは、以下のような命名規則になっています。

通常のフロー：英数字とハイフンで36文字
例）37ddc9f6-ee36-4e16-90f8-af0d38bb06f4

FlowInvokerで呼び出したフロー：通常のフローのリクエストID-枝番
例）37ddc9f6-ee36-4e16-90f8-af0d38bb06f4-1

ParallelSubFlowで呼び出したフロー：通常のフローのリクエストID_コンポーネント名-枝番
例）37ddc9f6-ee36-4e16-90f8-af0d38bb06f4_ParallelSubFlow1-1

📝 NOTE
枝番に最大値はありません。

Q40キューの上限値を超えた状態でさらにリクエストがきた場合はどうなりますか？

A

フローエンジンの実行スレッドがすべて処理中の場合、新しくきたリクエストはキューに格納され実行待ちの状態になります。このキューの上限値を超えた状態でさらにリクエストがくると、そのリクエストは実行されずに破棄されます。

フローサービスの実行モデルについては、フローサービスマニュアルの「はじめに」-「詳細なトピック」-「フローサービスのアーキテクチャ」-「フローサービスの実行モデル」を参照してください。

Q41管理コンソール以外にフローの実行状況を確認する方法はありますか？

A

フローの実行状況は、フローサービス管理コンソールの「状態」-「フロー」-「リクエスト一覧」を参照する以外に、flow-ctrlの「list request」コマンドで確認することができます。

flow-ctrlの「list request」コマンドを実行すると、 現在実行中およびキューで待機中のリクエストの一覧が表示されます。

＜表示される内容＞

  • リクエストID
  • フロー名
  • リクエストされたフロー名
  • セッションID
  • リクエスト時刻　（リクエストを受け付けた時刻)
  • 状態（以下のいずれか）
    • in queue — 既に実行中の他のフローが多く、フローがキューに入って実行を待っている状態
    • running — 実行中
    • suspend — デバッグ実行などの特殊な実行時において一時停止中になっている状態
    • end — フロー終了時の状態（既に終了したフローはリクエスト一覧に表示されません）

📝 NOTE
フローのさらに詳細な進行状況については、別途ログをファイル出力するなどして確認してください。

Q42フローの実行を強制終了するにはどうすればいいですか？

A

フローの実行を強制終了するには次の3つの方法があります。

フローデザイナーの実行ウィンドウから強制終了する場合

フローデザイナーの実行ウィンドウから実行したフローは、実行ウィンドウの右下にある「実行中止」ボタンをクリックすると強制終了することができます。 この方法で強制終了できるのはフローデザイナーの実行ウィンドウから実行したフローのみです。

管理コンソールから強制終了する場合

フローサービス管理コンソールの「状態」-「フロー」-「リクエスト一覧」画面で、強制終了したいリクエストを選んで強制終了します。キャンセルしたいリクエストを選択してリスト上部にある削除ボタンをクリックします。 （バージョン4.7.1以前の場合は、リストの右にあるキャンセルアイコンをクリックするか、またはチェックボックスをオンにしてリスト上部にある「一括キャンセル」ボタンをクリックします。）

flow-ctrlコマンドから強制終了する場合

kill request コマンドを使用します。

ただし、タイミングによって処理が中断命令を受け付けずに強制終了できないこともありますのでご注意ください。

Q43フローのどこで時間がかかっているのかを調べる方法はありますか？

A

フローの処理時間が長い時にボトルネックがどこにあるかを調べるために、プロファイルモードという実行モードが提供されています。この機能を使うと、各コンポーネントとフロー全体での実行時間を確認することができます。

下記のいずれかの方法で実行モードをプロファイルモードに変更します。変更後にフローを実行すると、処理時間の入った詳細なログがFlowProfile.logに出力されます。FlowProfile.logの内容から、フローのどこで時間がかかっているかを確認します。

📝 NOTE
FlowProfile.logの保存場所

バージョン1610以降
[DATA_DIR]/log/FlowProfile.log

バージョン4.9.1以前
[INSTALL_DIR]/flow/log/FlowProfile.log

FlowProfile.logの出力内容の詳細は「フローサービス オンラインマニュアル」の「フローデザイナー」-「フローの実行」-「フローの実行時情報」-「実行モード」-「プロファイル」を参照してください。 フローのボトルネックの特定については「フローサービスマニュアル」の「運用ガイド」-「パフォーマンス」-「パフォーマンスチューニング」-「ボトルネックの特定」を参照してください。

プロファイルモードの設定方法

プロファイルモードへは次の方法で変更できます。

フローデザイナーからフローを実行する場合

フローデザイナーの「フロー実行」ボタンをクリックして表示されるフローの実行画面で、「実行モード」を「通常」から「プロファイル」に変更して「実行」ボタンをクリックします。

実行設定からフローを実行する場合

  • フローデザイナーまたはトリガー管理の実行設定画面で、「実行モード」を「通常」から「プロファイル」に変更して「実行」ボタンまたは「登録」ボタンをクリックします。
  • フローサービス管理コンソールの「設定」-「トリガー」画面で、該当の実行設定を選択し「編集」ボタンをクリックして表示される画面で「実行モード」を「通常」から「プロファイル」に変更して「保存」ボタンをクリックします。 （バージョン4.7.1以前の場合は、「状態」-「実行設定」-「実行設定」画面で、「変更」アイコンをクリックして表示される画面で「Mode」を「通常」から「プロファイル」に変更して「更新」ボタンをクリックします。）

flow-ctrlコマンドからフローを実行する場合

execコマンドの実行時にオプション引数としてプロファイルモードを指定します。

exec Project1 Flow1 -mode:profile

Q44「フローの実行キャンセルがタイムアウトまでに完了しませんでした」というメッセージが表示されます

A

フローのキャンセル処理は一般的に実行中のコンポーネントの処理が終了したタイミングで行われます。 このメッセージは実行中のコンポーネントの処理時間が長く、内部的に指定されている時間内にキャンセルできなかった場合にタイムアウトを示すために表示しているだけで、キャンセル処理は無効ではありません。 該当のコンポーネントが終了した時点で、次の処理は行わずにフローの実行がキャンセルされてフローがアボートします。

例）以下のフローをキャンセルした場合

[Start]→[FileGet]→[FilePut]→[End]

上記フローで、FileGetコンポーネントの処理が長時間かかるとします。 FileGetコンポーネントの処理を開始したタイミングでフローの実行をキャンセルした場合、実際にフローがキャンセルされるのはFileGetコンポーネントの処理が終了したタイミングとなりますが、内部的に指定されている時間内にキャンセルできないため、キャンセル処理が行われる前にメッセージが表示されます。

以下のコンポーネントについては即時終了に対応しています。

ASTERIA Warp 4.4以降

  • RDBGet/RDBPut/RDBMerge/SQLCall
  • HTTPGet/HTTPPost/REST
  • FTPGet/FTPPut/FTPScript
  • Sleep
  • Mutex
  • EXE

ASTERIA Warp 4.5以降

  • FastInsert

ASTERIA Warp 4.8以降

  • ParallelSubFlow

「フローサービス管理コンソールオンラインヘルプ」の「状態」-「フロー」-「リクエスト一覧」も参照してください。

Q45外部からのトリガーでフローをデバッグできますか？

A

URL実行設定やメール監視実行設定など外部から起動したフローをデバッグすることができます。 フローデザイナーでフローを開き、「フローのデバッグ」ウィンドウの「外部からフローを実行する」チェックボックスをオンにします。「実行」ボタンをクリックすると、デバッガが実行されて待受中になります。この状態で、外部からのトリガーでフローを起動すると、デバッガがフローの開始コンポーネントで停止中になり、ここからデバッグすることができます。

Q46HttpEndで設定したCookieに有効期限を指定することはできますか？

A

HttpEndコンポーネントでCookieの有効期限を設定するには、「Cookie」プロパティの名前に「expires」を指定してDateTime型で値を設定します。

有効期限以外にも、サーバーのドメイン名やURLのサブセットを渡すこともできます。詳しくはHttpEndコンポーネントのヘルプを参照してください。

Q47「エラー(HttpStart1): ストリームのフォーマットではありません」というエラーになってしまいます

A

HttpStartコンポーネントで開始するフローをスケジュールで実行した場合などにこのエラーが出力されます。これは、HttpStartコンポーネントで開始するフローの起動時にParameterListストリームまたはMIMEストリームが入力されることを前提としていますが、スケジュール実行ではこのようなストリームがフローに渡されないためです。

HttpStartコンポーネントで開始するフローは必ずブラウザなどから実行するようにしてください。スケジュールで起動するフローはStartコンポーネントを使うようにしてください。

フロー起動のトリガーについては「フローサービスマニュアル」の「はじめに」-「トリガーごとのフローの作成」を参照してください。

Build: 1.0.0.176 | 2026-06-11 07:00