JP2017182573A - 情報処理装置、情報処理装置の制御方法、及びプログラム - Google Patents

Abstract

【課題】 ワークフローを実行する前に、ワークフローで用いられる機能プロバイダが要求されるジョブを実行できる状態であるか事前確認して、その応答結果を通知する。【解決手段】情報処理装置において、所定のジョブを実行する前に、前記ワークフローで使用される各機能プロバイダに対して、機能プロバイダが正常に動作する状態であるかを確認する確認要求を行う。そして、当該確認要求に対する各機能プロバイダから応答される事前確認結果にエラー通知が含まれていると判断した場合、対応する機能プロバイダの事前確認結果を通知する構成を特徴とする。【選択図】 図８

Description

本発明は、情報処理装置、情報処理装置の制御方法、及びプログラムに関するものである。

近年、オフィスに設置される情報処理装置である画像形成装置には、画像形成装置の機能を拡張できるシステムが普及している。拡張する機能（以降、拡張機能）は、ソフトウェアプログラム（以降、拡張ソフト）によって実現され、工場出荷時だけでなく、設置後の運用段階でも追加することが可能である。この種のシステムとしてはキヤノン株式会社のＭＥＡＰ（登録商標）などがあげられる。

特に、ある特定の目的のために作られた拡張ソフトは、アプリケーションソフトウェア（以降、アプリ）と呼ばれる。アプリは、画像形成装置が備えるファクシミリ、スキャナ、プリンタといった機能を利用することで目的の処理を実現している。画像形成装置は、ユーザの目的に応じて複数のアプリをインストールできるように構成されている。

また、アプリの中には、ワークフローアプリという実現手段がある。これは、機能の種類ごとに定められたインターフェースを持つ拡張ソフトである機能プロバイダという部品を、特定の処理としてフローとして組み合わせる。このフローを実行することで、様々な機能を組み合わせたアプリの実現を可能にする技術である。

一方、ユーザがワークフローアプリに実行指示した後に、ワークフローアプリが実際にジョブを実行することになるが、ワークフローアプリ実行時にエラーで終了することがある。しかし、ワークフローのジョブを実際に実行する前に知ることができる問題もある。このような実行時のエラーを防ぐために、ユーザからワークフローアプリに実行指示されたときに、ワークフローを実行できるか否かを判定し、実行できないと判定された際に、実行できない理由を表示させる情報処理装置が知られている。（例えば、特許文献１）

特開２００５−１９６４１４号公報

従来技術では、ワークフローに対する処理が実行できるか否かを、機能プロバイダであるプラグインではなく、機能プロバイダに処理を指示するワークフローアプリであるコアサービスで判断を行っている。また実行できない理由の表示もワークフローアプリで行っている。特許文献のようにワークフローアプリが機能プロバイダでの詳細なジョブ処理内容や、事前確認内容を把握できるような、ワークフローアプリと機能プロバイダが密に結合するような構成であれば、ワークフローアプリで事前確認処理を実行できる。

しかし、ワークフローアプリと機能プロバイダが疎に結合しており、呼び出される機能プロバイダが実行時に初めて決定し、ジョブ処理実行を機能プロバイダに移譲するような構成の場合、ワークフローアプリでは事前確認を行うことはできない。

すなわち、ワークフローアプリと機能プロバイダが疎に結合している構成では、ワークフローアプリは、実行時に決定する機能プロバイダや、各機能プロバイダでの詳細なジョブ処理内容や事前条件を全て把握するのは困難である。したがって、ワークフローアプリで、フロー実行時に事前確認を行うことができないという課題があった。

本発明は、上記の課題を解決するためになされたもので、本発明の目的は、ワークフローを実行する前に、ワークフローで用いられる機能プロバイダが要求されるジョブを実行できる状態であるか事前確認して、その応答結果を通知できる仕組みを提供することである。

上記目的を達成する本発明の情報処理装置は以下に示す構成を備える。

所定のジョブを実行する情報処理装置であって、特定の機能処理を実行する機能プロバイダを用いて所定のジョブワークフロー定義ファイルに記載されたワークフローを実行する実行手段と、前記所定のジョブを実行する前に、前記ワークフローで使用される各機能プロバイダに対して、機能プロバイダが正常に動作する状態であるかを確認する確認要求を行う要求手段と、前記要求手段による確認要求に対する各機能プロバイダから応答される事前確認結果にエラー通知が含まれているかどうかを判断する判断手段と、各機能プロバイダからの事前確認結果にエラー通知が含まれていると判断した場合、対応する機能プロバイダの事前確認結果を通知する通知手段と、を備えることを特徴とする。

本発明によれば、ワークフローを実行する前に、ワークフローで用いられる機能プロバイダが要求されるジョブを実行できる状態であるか事前確認して、その応答結果を通知できる。

画像処理システムのシステム構成の一例を示す図である。 ＭＦＰの構成を示すブロック図である。 サーバの構成を示すブロック図である。 ＭＦＰにおけるソフトウェア構成図である。 機能プロバイダ情報テーブルの一例を示す図である。 機能プロバイダインターフェース定義の例を示す図である。 ワークフロー定義ファイルの具体的な記述例を示す図である ＭＦＰ上のワークフロー実行の流れを示したシーケンス図である。 情報処理装置の制御方法を説明するフローチャートである。 ワークフロー処理部に返却される事前確認結果情報を示す図である。 事前確認結果画面の例を示す図である。 管理している詳細結果画面を示す図である。 ワークフロー実行の流れを示したシーケンス図である。 情報処理装置の制御方法を説明するフローチャートである。 情報処理装置の制御方法を説明するフローチャートである。 情報処理装置の制御方法を説明するフローチャートである。

次に本発明を実施するための最良の形態について図面を参照して説明する。
＜システム構成の説明＞
〔第１実施形態〕

図１は、本実施形態の画像処理システムのシステム構成の一例を示す図である。本システムは、ＬＡＮ１１０を介して接続されるＭＦＰ１０１と、ＷＡＮ１２０を介して接続されるサーバから構成される。ＬＡＮ１１０上の装置とＷＡＮ上の装置はお互いのネットワークを通して、相互に通信可能である。図１は典型的なネットワーク構成の例であり、各装置がＬＡＮ１１０またはＷＡＮ１２０のどちらにあっても構わない。

図１において、ＭＦＰ１０１は、スキャナ、プリンタを有する画像形成装置である。加えて、装置上で動作する拡張ソフトを追加、実行させるためのソフトウェアプラットホームを持つ。ＭＦＰ１０１は、さらに公衆回線網とつながりファクス送受信が可能である。サーバ１０２は、ＭＦＰ１０１と連携して各種処理を行うサーバ１０２である。例えば、ＭＦＰ１０１から、様々なプロトコル、例えばＳＭＢ（Ｓｅｒｖｅｒ Ｍｅｓｓａｇｅ Ｂｌｏｃｋの略称）やＦＴＰ（Ｆｉｌｅ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌの略称）で画像データを受信するファイルサーバであったりする。またＭＦＰ１０１から処理依頼を受けてＯＣＲ（光学文字認識）処理を実行するアプリケーションサーバであったりする。またＭＦＰ１０１から依頼を受けてメールを送信するメールサーバであったりする。またＭＦＰ１０１からの要求に従ってＨＴＭＬを送信するＷｅｂサーバであったりする。サーバは一台とは限らず、目的に応じて複数のサーバが存在してもよい。

図２は、図１に示したＭＦＰ１０１の構成を示すブロック図である。
図２において、ＣＰＵ２１１を含む制御部２１０は、ＭＦＰ１０１全体の動作を制御する。ＣＰＵ２１１は、ＲＯＭ２１２やＨＤＤ２１４に記憶された制御プログラムを読み出して読取制御や送信制御などの各種制御処理を実行する。ＲＡＭ２１３は、ＣＰＵ２１１の主メモリ、ワークエリア等の一時記憶領域として用いられる。ＨＤＤ２１４は、画像データやインストールされた拡張ソフトを含む各種プログラムを記憶する。操作部Ｉ／Ｆ２１５は、操作部２２０と制御部２１０とを接続する。操作部２１９には、タッチパネル機能を有する液晶表示部やキーボードなどが備えられている。

プリンタＩ／Ｆ２１６は、プリンタ２２１と制御部２１０とを接続する。プリンタ２２１で印刷すべき画像データはプリンタＩ／Ｆ２１６を介して制御部２２０からプリンタに転送され、プリンタ２２１において記録媒体上に印刷される。スキャナＩ／Ｆ２１７は、スキャナ２２２と制御部２１０とを接続する。スキャナ２２２は、原稿上の画像を読み取って画像データを生成し、スキャナＩ／Ｆ２１７を介して制御部に入力する。またスキャナＩ／Ｆ２１７には、不図示の画像解析ボードが接続され、画像解析ボードにより入力された画像データに対してＯＣＲ処理を行ったりする。

ネットワークＩ／Ｆ２１８は、制御部２１０（ＭＦＰ１０１）をＬＡＮ１１０に接続する。ネットワークＩ／Ｆは、ＬＡＮ１１０上またはＷＡＮ上の他の装置との間で各種情報を送受信する。モデム２１９は、制御部２１０（ＭＦＰ１０１）を公衆回線網１３０に接続する。モデム２１９は、公衆回線網上の他の装置との間でファクスを送受信する。

図３は、図１に示したサーバ１０２の構成を示すブロック図である。
図において、ＣＰＵ３１１を含む制御部３１０は、サーバ全体の動作を制御する。ＣＰＵ３１１は、ＲＯＭ３１２やＨＤＤ３１４に記憶された制御プログラムを読み出して各種制御処理を実行する。ＲＡＭ３１３は、ＣＰＵ３１１の主メモリ、ワークエリア等の一時記憶領域として用いられる。ＨＤＤ３１４は、各種のプログラムやデータを記憶する。

表示部Ｉ／Ｆ３１５は、表示部３１８と制御部３１０とを接続する。キーボードＩ／Ｆ３１６は、キーボード３１９と制御部３１０とを接続する。ＣＰＵ３１１は、キーボード３１９を介したユーザからの指示を認識し、認識した指示に応じて表示部３１８に表示する画面を遷移させる。
ネットワークＩ／Ｆ３１７は、制御部３１０（サーバ１０２）をＷＡＮ１２０に接続する。ネットワークＩ／Ｆ３１７は、ＬＡＮ１１０上またはＷＡＮ１２０上の他の装置との間で各種情報を送受信する。

図４は、本実施形態のＭＦＰ１０１におけるソフトウェア構成図である。ＭＦＰ１０１のＨＤＤに記憶されているプログラム（ソフトウェア）を、ＣＰＵがＲＡＭに読み出し、解析、実行することで、図８、図９、図１３、図１４、図１５および図１６のフローチャートの処理が実行される。

図４において、拡張ソフト管理部４１０は、ＭＦＰ１０１上で拡張ソフトを動作させるためのソフトウェアプラットホームである。図４では、拡張ソフトとして４１１〜４１７の７つの機能プロバイダがＭＦＰ１０１にインストールされている。

機能プロバイダは、拡張ソフトの一種であるが、アプリではない。アプリは単体で入力から出力までの一連の完結した処理を備えている。一方、単体の機能プロバイダは入力なら入力、出力なら出力といった特定の機能に特化したものであり、入力から出力までの一連の完結した処理を行うためには、複数の機能プロバイダを組み合わせる必要がある。
例えば、「スキャンしてＯＣＲ処理の後、送信する」という機能をユーザに提供する場合、アプリであれば「スキャン」「ＯＣＲ処理」「送信」の３つの機能を３つのアプリで実現する。

一方、機能プロバイダの場合、「スキャン機能を実現する機能プロバイダ」、「ＯＣＲ機能を実現する機能プロバイダ」、「送信機能を実現する機能プロバイダ」の３つの機能プロバイダが必要になる。さらに、それら３つの機能プロバイダを一連の処理として実行するためには、後述するワークフロー処理部４３０が必要になる。なお、ワークフロー処理部４３０は、特定の機能処理を実行する機能プロバイダを用いて所定のジョブワークフロー定義ファイルに記載されたワークフローを実行する。その際、ワークフローを実行する前に、機能プロバイダが正常に動作する状態であるかを確認する確認要求を、例えば図８に示すように実行する。

また、アプリは、ＭＦＰ１０１が元々備えている機能（例えばコピー機能やファクス送信機能）を呼び出すためのメニュー画面に、それらの機能と横並びで表示されるようにアプリ自身を登録する。アプリは、メニュー画面からユーザの指示によって呼び出される。

一方、機能プロバイダはメニュー画面ではなく、後述する機能プロバイダ管理部４２０に、機能プロバイダ自身を登録する。機能プロバイダは、機能プロバイダ管理部４２０経由でワークフロー処理部４３０の指示によって呼び出される。

さらに、機能プロバイダは、後述する機能プロバイダ管理部４２０が規定するルール（以降「機能プロバイダインターフェース」）を満たすようにプログラミングされている。機能プロバイダインターフェースは、ソフトウェア間のやり取りを行う際のルールを決めたソフトウェアインターフェースである。機能プロバイダインターフェースは、機能プロバイダが提供する機能の種類（以降「
機能タイプ」）ごとに定められている。機能プロバイダは、機能プロバイダインターフェースに基づいてワークフロー処理部４３０から呼び出される。

なお、１つの機能プロバイダは目的に応じて、複数種類のインターフェースを持つ場合がある。例えば、スキャン機能を実現する機能プロバイダであれば、「スキャン設定画面の表示」の目的のためのインターフェースと「スキャンジョブの実行」の目的のためのインターフェースといったように、目的別に複数種類のインターフェースを用意することができる。

また、複数種類の機能プロバイダをＭＦＰ１０１にインストールすることができる。異なる機能タイプの機能プロバイダを複数種類インストールしてもよいし、同じ機能タイプの機能プロバイダを複数種類インストールしてもよい。同じ機能タイプの機能プロバイダは同じソフトウェアインターフェースを持つため、拡張ソフトは、同じ機能タイプの機能プロバイダであれば、同じようにソフトウェア間のやり取りを行うことができる。

標準スキャンプロバイダ４１１は、スキャン機能を提供する機能プロバイダ（機能タイプ＝スキャン）である。機能タイプが「スキャン」の機能プロバイダを総称してスキャンプロバイダと呼ぶ。スキャンプロバイダは、機能タイプが「スキャン」の機能プロバイダのために定義された機能プロバイダインターフェース（スキャンプロバイダインターフェース）を実現する。標準スキャンプロバイダ４１１は、一般的なユーザ向けのスキャン設定画面を持つ。また標準スキャンプロバイダ４１１は、標準スキャンプロバイダ４１１が正常に機能を提供できるか否かを判断する事前確認機能を持つ。例えば、標準スキャンプロバイダ４１１は、例えばスキャナＩ／Ｆ２１７を通じてスキャナ２２２の接続状況を確認したりする。

組込ＯＣＲプロバイダ４１２とＷｅｂ ＯＣＲプロバイダ４１３は、ともにＯＣＲ機能を提供する機能プロバイダ（機能タイプ＝ＯＣＲ）である。機能タイプが「ＯＣＲ」の機能プロバイダを総称してＯＣＲプロバイダと呼ぶ。ＯＣＲプロバイダは、機能タイプが「ＯＣＲ」の機能プロバイダのために定義された機能プロバイダインターフェース（ＯＣＲプロバイダインターフェース）を実現する。組込ＯＣＲプロバイダ４１２は、ＭＦＰ１０１上で文字認識処理を行うことでＯＣＲ機能を提供する。一方、Ｗｅｂ ＯＣＲプロバイダ４１３は、外部のＷｅｂサーバ（例えばサーバ）が提供する文字認識処理を呼び出すことでＯＣＲ機能を提供する。また組込ＯＣＲプロバイダ４１２やＷｅｂ ＯＣＲプロバイダ４１３は、組込ＯＣＲプロバイダ４１２やＷｅｂ ＯＣＲプロバイダ４１３が正常に機能を提供できるか否かを判断する事前確認機能を持つ。例えば、組込ＯＣＲプロバイダ４１２はスキャナＩ／Ｆ２１７を通じて画像解析ボードの接続状況を確認したり、画像解析ボードを有効化するために必要なオプションライセンス情報がＨＤＤに保存されているかを確認したりする。また、例えば、Ｗｅｂ ＯＣＲプロバイダ４１３は、ネットワークＩ／Ｆ２１８を通じてサーバ１０２との接続状態を確認したり、サーバ１０２でのＯＣＲ処理を依頼するのに必要なアカウントが設定されているかを確認したりする。

ＳＭＢ取得プロバイダ４１４とＢｏｘ取得プロバイダ４１５は、ファイル取得機能を提供する機能プロバイダ（機能タイプ＝ファイル取得）である。機能タイプが「ファイル取得」の機能プロバイダを総称してファイル取得プロバイダと呼ぶ。ファイル取得プロバイダは、機能タイプが「ファイル取得」の機能プロバイダのために定義された機能プロバイダインターフェース（ファイル取得プロバイダインターフェース）を実現する。ＳＭＢ取得プロバイダ４１４は、ネットワークＩ／Ｆを通じて外部のファイルサーバ（例えばサーバ）からＳＭＢプロトコルによりファイルを取得する機能を提供する。一方、Ｂｏｘ取得プロバイダ４１５は、ＭＦＰ１０１のＨＤＤ上に設けられたファイル格納機能であるＢｏｘからファイルを取得する機能を提供する。またＳＭＢ取得プロバイダ４１４やＢｏｘ取得プロバイダ４１５は、ＳＭＢ取得プロバイダ４１４やＢｏｘ取得プロバイダ４１５が正常に機能を提供できるか否かを判断する事前確認機能を持つ。

例えば、ＳＭＢ取得プロバイダ４１４は、ネットワークＩ／Ｆ２１８を通じてサーバ１０２への接続状況を確認したり、サーバ１０２に接続するためのアカウント設定を確認したり、サーバ１０２に取得すべきファイルが格納されているか確認したりする。

また、例えば、Ｂｏｘ取得プロバイダ４１５は、ＭＦＰ１０１上のＢｏｘ機能を搭載しているかを確認したり、アカウント設定を確認したり、Ｂｏｘ上に取得すべきファイルが格納されているか確認したりする。

ＦＡＸ送信プロバイダ４１６とメール送信プロバイダ４１７は、ファイル送信機能を提供する機能プロバイダ（機能タイプ＝ファイル送信）である。機能タイプが「ファイル送信」の機能プロバイダを総称してファイル送信プロバイダと呼ぶ。ファイル送信プロバイダは、機能タイプが「ファイル送信」の機能プロバイダのために定義された機能プロバイダインターフェース（ファイル送信プロバイダインターフェース）を実現する。

ＦＡＸ送信プロバイダ４１６は、モデム２１９を通じて公衆回線網１３０に接続されている外部のファクスに対してファイルを取得する機能を提供する。一方、メール送信プロバイダ４１７は、ネットワークＩ／Ｆ２１８を通じてメールサーバ（例えばサーバ）に対してメール送信を依頼する機能を提供する。またＦＡＸ送信プロバイダ４１６やメール送信プロバイダ４１７は、ＦＡＸ送信プロバイダ４１６やメール送信プロバイダ４１７が正常に機能を提供できるか否かを判断する事前確認機能を持つ。

例えば、ＦＡＸ送信プロバイダ４１６は、モデム２１９の装着状況を確認したり、モデム２１９を有効化するためのライセンスがＨＤＤ２１４に格納されているか確認したりする。またＦＡＸ送信プロバイダ４１６は、ファクス送信時に使用する送信元情報の設定を確認したり、モデム２１９を通じて公衆回線網への接続状況を確認したりする。また、例えば、メール送信プロバイダ４１７は、ネットワークＩ／Ｆ２１８を通じてサーバ１０２への接続状況を確認したり、サーバ１０２に接続するためのアカウント設定を確認したりする。
各機能プロバイダは、ＭＦＰ１０１に同じ機能タイプを持つ機能プロバイダが他に存在しなくても、自身の機能タイプ用に定義された機能プロバイダインターフェースを実現する。
以上で説明した４１１〜４１７の７つの機能プロバイダは一例であり、ＭＦＰ１０１には、拡張ソフトとして様々な機能プロバイダを追加・削除することが可能である。

機能プロバイダ管理部４２０は、ＭＦＰ１０１にインストールされている機能プロバイダを管理するソフトウェアである。機能プロバイダ管理部４２０は、機能プロバイダ登録部４２１、機能プロバイダ検索部４２２、機能プロバイダ情報テーブル４２３、機能プロバイダインターフェース４２４定義を持つ。

機能プロバイダ登録部４２１は、各機能プロバイダからの依頼を受けて、機能プロバイダ情報テーブル４２３に、各機能プロバイダの機能タイプや設定可能な値などの情報を登録する。機能プロバイダ検索部４２２は、後述するワークフロー処理部４３０から機能プロバイダの検索条件を受け取り、機能プロバイダ情報テーブル４２３の情報をもとに条件に一致する機能プロバイダを特定する。機能プロバイダ検索部４２２は、検索結果として機能プロバイダを１つに特定するため、検索条件に一致する機能プロバイダが複数存在した場合は、最も優先順位の高い機能プロバイダを検索結果とする。機能プロバイダインターフェース定義４２４は、機能プロバイダインターフェースを定義している。

ワークフロー処理部４３０は、後述するワークフロー定義ファイル４４０に従って複数の機能プロバイダを組み合わせて一連の処理として実行する。本発明では、ワークフローとは、複数の機能プロバイダを組み合わせた一連の処理を差すものとする。

ワークフロー定義ファイル４４０は、ワークフロー処理部４３０が呼び出す機能プロバイダの検索条件や、呼び出し順序、呼び出した機能プロバイダに適用する設定値など、機能プロバイダの呼び出しに関する情報を定義する。なお、図ではワークフロー定義ファイルを例として１つ定義しているが、１つに限定するものではなく、ＭＦＰ１０１上に複数のワークフロー定義ファイルが存在してもよい。

図５は、図４に示した機能プロバイダ情報テーブル４２３の一例を示す図である。
図５において、機能プロバイダ情報テーブル４２３は、機能プロバイダを一意に特定する機能プロバイダＩＤ、機能プロバイダの名称、機能タイプ、機能プロバイダインターフェースなど、機能プロバイダに関する情報を保持する。

図６は、本実施形態における機能プロバイダインターフェース定義の例を示す図である。本実施形態では機能プロバイダインターフェースはプログラムのソースコード形式で表現されているが、これに限定されるものではなく、他の形式であってもよい。

図６において、６０１はスキャンプロバイダインターフェースの定義で、「ｓｈｏｗ Ｓｅｔｔｉｎｇ ＵＩｄｏ Ｓｃａｎ」「ｄｏ Ｓｃａｎ Ｗｉｔｈ Ｓｅｔｔｉｎｇ ＵＩ」「ｐｒｅ Ｃｈｅｃｋ」という４つのインターフェースを定義している。スキャンプロバイダは、で定義している３つのインターフェースを必ず備えている。

「ｓｈｏｗ Ｓｅｔｔｉｎｇ ＵＩ」はスキャン設定画面を表示するためのインターフェースで、Ｐａｒａｍｅｔｅｒを受け取り、結果をｂｏｏｌｅａｎ（真偽値）で返す。ユーザがスキャン設定を確定するとｔｒｕｅ（真）を返し、ユーザがスキャン設定をキャンセルするとｆａｌｓｅ（偽）を返す。Ｐａｒａｍｅｔｅｒは、インターフェースを呼び出す際の設定値で、ワークフロー定義ファイル４４０で定義される。「ｄｏ Ｓｃａｎ」はスキャン実行のためのインターフェースで、Ｐａｒａｍｅｔｅｒを受け取り、結果をＤｏｃｕｍｅｎｔというデータ形式で返す。「ｄｏ ｃａｎ」は「ｓｈｏｗ Ｓｅｔｔｉｎｇ ＵＩ」でユーザが設定した値またはＰａｒａｍｅｔｅｒで指定された設定値でスキャンを実行する。「ｄｏ Ｓｃａｎ Ｗｉｔｈ Ｓｅｔｔｉｎｇ ＵＩ」は、スキャン設定画面を表示後、ユーザが設定画面で確定した値でスキャンを実行する。「ｐｒｅ Ｃｈｅｃｋ」はスキャン事前情報確認を実行するためのインターフェースで、Ｐａｒａｍｅｔｅｒを受け取り、結果をＣｈｅｃｋ Ｒｅｓｕｌｔという事前確認結果情報の形式で返す。

同様に、６０２はＯＣＲプロバイダインターフェースの定義、６０３はファイル取得プロバイダインターフェースの定義、６０４はファイル送信プロバイダインターフェースの定義である。このように、機能プロバイダインターフェース定義では、各機能プロバイダが備えるインターフェース（名称、入力、出力）を定義している。

図７は、本実施形態におけるワークフロー定義ファイルの具体的な記述例を示す図である。本実施形態ではワークフロー定義ファイルはＸＭＬ形式のファイルとして表現されているが、ＸＭＬ形式に限定されるものではなく、他の形式のファイルであってもよい。
Ｗｏｒｋｆｌｏｗタグ７００は、以下の記述がワークフローの定義であることを示している。

図７において、ＦＰタグ７０１は、Ｗｏｒｋｆｌｏｗタグの子要素で、ワークフローで実行する機能プロバイダに関する情報を定義している。ＦＰタグ７０１のｎｏ属性は、ワークフローにおける機能プロバイダの実行順を定義しており、「ｎｏ＝"１"」は最初に実行する機能プロバイダであることを示している。ＦＰタグ７０１のｔｙｐｅ属性は、実行する機能プロバイダの機能タイプを定義しており、「ｔｙｐｅ＝"ＳＣＡＮ"」はスキャンプロバイダであることを示している。

Ｃｏｎｄｉｔｉｏｎタグ７０２は、ＦＰタグ７０１の子要素で、スキャンプロバイダの検索条件を子要素であるＲｅｑｕｉｒｅｄタグとＯｐｔｉｏｎａｌタグで定義している。Ｒｅｑｕｉｒｅｄタグは、検索するスキャンプロバイダの必須条件を定義しており、「ＤＯＣＵＭＥＮＴ＿ＦＯＲＭＡＴ（ファイル形式）」の設定値として「ＰＤＦ」を設定可能なスキャンプロバイダが必須である旨を示している。Ｏｐｔｉｏｎａｌタグは、検索するスキャンプロバイダのオプション条件を定義しており、「ＯＲＩＧＩＮＡＬ＿ＴＹＰＥ（原稿種類）」の設定値として「ＴＥＸＴ」を設定可能なスキャンプロバイダを優先的に使用する旨を示している。

ここで必須条件とオプション条件の違いを説明する。機能プロバイダの検索処理において、必須条件は必ず満たすべき条件であり、必須条件を満たす機能プロバイダが存在しない場合、検索結果は「なし」となる。一方、オプション条件は、オプション条件を満たす機能プロバイダを優先的に使用する条件であり、オプション条件を満たす機能プロバイダが存在しない場合、オプション条件は検索条件から除外される。

Ａｃｔｉｏｎタグ７０３は、ＦＰタグ７０１の子要素であり、機能プロバイダの呼び出しについての情報を定義している。Ａｃｔｉｏｎタグ７０３のｎｏ属性とｍｅｔｈｏｄ属性は、ＦＰタグで定義された機能プロバイダの中での実行順と呼び出すインターフェースを定義している。Ａｃｔｉｏｎタグ７０３は、スキャンプロバイダの実行において「ｄｏ Ｓｃａｎ Ｗｉｔｈ ｓｈｏｗ Ｓｅｔｔｉｎｇ ＵＩ」を１番目に呼び出す旨を定義している。Ｐａｒａｍｅｔｅｒタグ７０４はＡｃｔｉｏｎ７０３の子要素であり、Ａｃｔｉｏｎ７０３で定義されているインターフェース（ｄｏ Ｓｃａｎｉｔｈ ｓｈｏｗ Ｓｅｔｔｉｎｇ ＵＩ）を呼び出す際に渡す設定値を定めている。Ｏｕｔｐｕｔ７０５タグは、「ｄｏ Ｓｃａｎ」の出力に関する定義であり、ｔｙｐｅ属性で出力形式が「Ｄｏｃｕｍｅｎｔ」である旨と、ｉｄ属性で出力データを一意に特定するＩＤが「ｆｏｏ」である旨を定義している。

ＦＰタグ７０６は、ｎｏ属性とｔｙｐｅ属性で、２番目に実行する機能プロバイダがＯＣＲプロバイダであることを定義している。Ｒｅｑｕｉｒｅｄタグは、ＯＣＲプロバイダの必須条件を定義しており、「ＬＡＮＧ（認識言語）」の設定値として「ＪＡ（日本語）」を設定可能なＯＣＲプロバイダが必須である旨を示している。

Ａｃｔｉｏｎタグ７０７は、ＦＰタグ７０６の子要素であり、ＯＣＲプロバイダの実行において「ｄｏＯＣＲ」を１番目に呼び出す旨を定義している。Ｉｎｐｕｔタグは、「ｄｏＳｃａｎ」の入力に関する定義で、「Ｄｏｃｕｍｅｎｔ」形式のデータをＩＤが「ｆｏｏ」のデータから受け取ることを示している。つまり、ＯＣＲプロバイダは、スキャンプロバイダのスキャンデータをＤｏｃｕｍｅｎｔ形式で受け取るということを定義している。Ｏｕｔｐｕｔタグ７０８は、「ｄｏＯＣＲ」の出力に関する定義であり、ｔｙｐｅ属性で出力形式が「Ｓｔｒｉｎｇ」である旨と、ｉｄ属性で出力データを一意に特定するＩＤが「ｂａｒ」である旨を定義している。

ＦＰタグ７０９は、ｎｏ属性とｉｄ属性で、３番目に実行する機能プロバイダがＳＭＢ取得プロバイダ４１４であることを定義している。ＦＰタグ７０９は機能プロバイダを、ＦＰタグ７０１、７０６のようにｔｙｐｅ属性を使って機能タイプで指定することもできるし、ＦＰタグ７０９のようにｉｄ属性を使って一意に指定することもできる。

Ａｃｔｉｏｎタグ７１０は、ＳＭＢ取得プロバイダ４１４の実行において「ｄｏＧｅｔ」を２番目に呼び出す旨を定義している。ＰａｒａｍｅｔｅｒタグはＡｃｔｉｏｎタグ７１０の子要素であり、Ａｃｔｉｏｎタグ７１０で定義されているインターフェース（ｄｏＧｅｔ）を呼び出す際に渡す設定値を定めている。Ｏｕｔｐｕｔ７１１タグは、「ｄｏＧｅｔ」の出力に関する定義であり、ｔｙｐｅ属性で出力形式が「Ｄｏｃｕｍｅｎｔ」である旨と、ｉｄ属性で出力データを一意に特定するＩＤが「ｂａｚ」である旨を定義している。

ＦＰタグ７１２は、ｎｏ属性とｉｄ属性で、番目に実行する機能プロバイダがＦＡＸ送信プロバイダ４１６であることを定義している。Ａｃｔｉｏｎタグ７１３は、ＦＡＸ送信プロバイダ４１６の実行において「ｄｏＳｅｎｄ」を２番目に呼び出す旨を定義している。Ｉｎｐｕｔタグは、ＦＡＸ送信プロバイダ４１６の「ｄｏＳｅｎｄ」呼び出しの入力に関する定義で、「Ｄｏｃｕｍｅｎｔ」のＩＤが「ｂａｚ」のデータを「ｄｏＧｅｔ」の出力から受け取ることを示している。Ｉｎｐｕｔタグは、「Ｄｏｃｕｍｅｎｔ」のＩＤが「ｆｏｏ」のデータを「ｄｏＳｅｎｄ」の出力から受け取ることを示している。さらに、Ｉｎｐｕｔタグは、「Ｓｔｒｉｎｇ」のＩＤが「ｂａｒ」のデータを「ｄｏＯＣＲ」の出力から受け取ることを示している。

〔第１のシーケンス例〕
図８は、本実施形態におけるＭＦＰ１０１上のワークフロー実行の流れを示したシーケンス図である。
図８において、Ｓ８０１において、ユーザからのワークフロー実行指示をワークフロー処理部４３０が受け取る。
Ｓ８０２において、ワークフロー処理部４３０が実行指示に対するワークフロー定義ファイル４４０を読み込む。ここでは、図で示したワークフロー定義ファイル４４０のように、まず「機能タイプがＳＣＡＮの機能プロバイダ」、「機能タイプがＯＣＲの機能プロバイダ」を順に実行するように定義されているものとする。その後「機能プロバイダＩＤがＧＥＴ＿ＳＭＢの機能プロバイダ」、「機能プロバイダＩＤがＳＥＮＤ＿ＦＡＸの機能プロバイダ」を順に実行するように定義されているものとする。

Ｓ８０３において、ワークフロー処理部４３０は、Ｓ８１９で実際にワークフローを開始する前に、機能プロバイダ管理部４２０に対して、ワークフロー定義ファイルに記載されている機能プロバイダの検索を指示する。ここでは「機能タイプがＳＣＡＮの機能プロバイダ」、「機能タイプがＯＣＲの機能プロバイダ」、「機能プロバイダＩＤがＧＥＴ＿ＳＭＢの機能プロバイダ」、「機能プロバイダＩＤがＳＥＮＤ＿ＦＡＸの機能プロバイダ」の機能プロバイダの検索を指示する。

Ｓ８０４において、機能プロバイダ管理部４２０は、機能プロバイダ情報テーブル４４０をもとに検索条件に一致する機能プロバイダを抽出する。本例では、標準スキャンプロバイダ４１１、組込ＯＣＲプロバイダ４１２、ＳＭＢ取得プロバイダ４１４、ＦＡＸ送信プロバイダ４１６が抽出されるものとする。
Ｓ８０５において、機能プロバイダ管理部４２０は、Ｓ８０４での機能プロバイダの検索結果を、ワークフロー処理部４３０に通知する。

Ｓ８０６において、検索結果を受け取ったワークフロー処理部４３０は、Ｓ８０５で取得した標準スキャンプロバイダ４１１に対して、事前確認指示を行う。すなわち、ワークフロー処理部４３０は、標準スキャンプロバイダ４１１に対して、機能プロバイダインターフェース定義４２４のスキャンプロバイダインターフェース６０１で定義されている「ｐｒｅＣｈｅｃｋ」メソッドの実行を指示する。

Ｓ８０７において、指示を受け取った標準スキャンプロバイダ４１１は、事前確認処理を行う。標準スキャンプロバイダ４１１は、事前確認処理として、スキャナＩ／Ｆ２１７を通じてスキャナ２２２の接続状況を確認し、正常にスキャン機能を提供できるか否かを判断する。
Ｓ８０８において、標準スキャンプロバイダ４１１は、前記Ｓ８０７で判断した事前確認結果を、ワークフロー処理部４３０に返却する。

Ｓ８０９において、ワークフロー処理部４３０は、Ｓ８０５で取得した組込ＯＣＲプロバイダ４１２に対して、事前確認指示を行う。すなわち、ワークフロー処理部４３０は、組込ＯＣＲプロバイダ４１２に対して、機能プロバイダインターフェース定義４２４のＯＣＲプロバイダインターフェースで定義されている「ｐｒｅＣｈｅｃｋ」メソッドの実行を指示する。

Ｓ８１０において、指示を受け取った組込ＯＣＲプロバイダ４１２は、事前確認処理を行う。組込ＯＣＲプロバイダ４１２は、事前確認処理として、スキャナＩ／Ｆ２１７を通じて画像解析ボードの接続状況を確認したり、画像解析ボードを有効化するために必要なオプションライセンス情報がＨＤＤ２１４に保存されているかを確認したりする。そして組込ＯＣＲプロバイダ４１２は、正常に組込ＯＣＲ機能を提供できるか否かを判断する。Ｓ８１０において、組込ＯＣＲプロバイダ４１２は、前記ステップで判断した事前確認結果を、ワークフロー処理部４３０に返却する。

Ｓ８１２において、ワークフロー処理部４３０は、Ｓ８０５で取得したＳＭＢ取得プロバイダ４１４に対して、事前確認指示を行う。すなわち、ワークフロー処理部４３０は、ＳＭＢ取得プロバイダ４１４に対して、機能プロバイダインターフェース定義のファイル取得プロバイダインターフェースで定義されている「ｐｒｅＣｈｅｃｋ」メソッドの実行を指示する。

Ｓ８１３において、指示を受け取ったＳＭＢ取得プロバイダ４１４は、事前確認処理を行う。ＳＭＢ取得プロバイダ４１４は、事前確認処理として、ネットワークＩ／Ｆ２１８を通じてサーバ１０２への接続状況を確認し、サーバ１０２に接続するためのアカウント設定を確認し、サーバ１０２に取得すべきファイルが格納されているか確認する。そしてＳＭＢ取得プロバイダ４１４は、正常にＳＭＢファイル取得機能を提供できるか否かを判断する。Ｓ８１４において、ＳＭＢ取得プロバイダ４１４は、前記Ｓ８１３で判断した事前確認結果を、ワークフロー処理部４３０に返却する。

Ｓ８１５において、ワークフロー処理部４３０は、Ｓ８０５で取得したＦＡＸ送信プロバイダ４１６に対して、事前確認指示を行う。すなわち、ワークフロー処理部４３０は、ＦＡＸ送信プロバイダ４１６に対して、機能プロバイダインターフェース定義４２４のＦＡＸ送信プロバイダインターフェース６０４で定義されている「ｐｒｅＣｈｅｃｋ」メソッドの実行を指示する。

Ｓ８１６において、指示を受け取ったＦＡＸ送信プロバイダ４１６は、事前確認処理を行う。ＦＡＸ送信プロバイダ４１６は、事前確認処理として、モデム２１９の装着状況を確認し、モデム２１９を有効化するためのライセンスがＨＤＤに格納されているか確認する。そして、ＦＡＸ送信プロバイダ４１６は、正常にＦＡＸ送信機能を提供できるか否かを判断する。Ｓにおいて、ＦＡＸ送信プロバイダ４１６は、前記ステップ８１６で判断した事前確認結果を、ワークフロー処理部４３０に返却する。

Ｓ８１７において、ワークフロー処理部４３０は、Ｓ８０８、Ｓ８１１、Ｓ８１４、Ｓ８１７で受信した事前確認結果の中から、ＮＧ、すなわち、実行不可の旨を受信した件数が０件より多いかを判断する。ワークフロー処理部４３０は、ＮＧの件数が０件より大きいと判断した場合は、処理はＳ８１８に進み、そうではない場合は、処理はＳ８１９に進む。
Ｓ８１８において、ワークフロー処理部４３０が、Ｓ８１７において、事前確認結果のＮＧの件数が０より多いと判断した場合に、フローを終了させる。そして処理は終了する。

Ｓ８１９において、ワークフロー処理部４３０が、Ｓ８１７において、事前確認結果のＮＧの件数が０より多くないと判断した場合に、フロー処理を実行する。すなわち、ワークフロー処理部４３０は、標準スキャンプロバイダ４１１に対してスキャン実行を指示する。

Ｓ８２０において、指示を受けた標準スキャンプロバイダ４１１は、スキャン処理を実行し、その結果をワークフロー処理部４３０に対して送信する。Ｓ８２１において、ワークフロー処理部４３０は、組込ＯＣＲプロバイダ４１２に対してＯＣＲ実行を指示する。

Ｓ８２２において、指示を受けた組込ＯＣＲプロバイダ４１２は、組込ＯＣＲ処理を実行し、その結果をワークフロー処理部４３０に対して送信する。Ｓ８２３において、ワークフロー処理部４３０は、ＳＭＢ取得プロバイダ４１４に対してＳＭＢファイル取得の実行を指示する。

Ｓ８２４において、指示を受けたＳＭＢ取得プロバイダ４１４は、ＳＭＢファイル取得処理を実行し、その結果をワークフロー処理部４３０に対して送信する。Ｓ８２５において、ワークフロー処理部４３０は、ＦＡＸ送信プロバイダ４１６に対してファクス送信実行を指示する。

Ｓ８２６において、指示を受けたＦＡＸ送信プロバイダ４１６は、ファクス送信処理を実行し、その結果をワークフロー処理部４３０に対して送信する。Ｓ８２７において、ワークフロー処理部４３０は、操作部Ｉ／Ｆ２１５を通じて、操作部２２０にフロー処理実行結果を表示する。そして、本処理は終了する。

図９は、本実施形態を示す情報処理装置の制御方法を説明するフローチャートである。本例は、ＭＦＰ１０１におけるワークフロー実行処理例である。各ステップは、ＭＦＰ１０１のＨＤＤ２１４に記憶されているプログラムを、ＣＰＵ２１１がＲＡＭ２１３に読み出し、解析、実行することで実現される。
Ｓ９０１において、まずワークフロー処理部４３０は、ユーザからワークフローの実行指示を受け取る。Ｓ９０２において、ワークフロー処理部４３０は、実行指示に対応するワークフロー定義ファイルを読み込む。

Ｓ９０３において、ワークフロー処理部４３０はワークフロー定義ファイルからＦＰタグで定義された機能プロバイダの定義を実行順に１つ取り出す。ここで、実行順とは、ＦＰタグのｎｏ要素に定義された数字の若い順を意味する。

Ｓ９０４において、ワークフロー処理部４３０は、次に実行すべき機能プロバイダがあればＳ９０５へ進み、次に事前確認を実行すべき機能プロバイダがなければ（最後の機能プロバイダまで取得し終えたら）、処理はＳ９１１に進む。
Ｓ９０６において、ワークフロー処理部４３０は、ＦＰタグから機能プロバイダの検索条件を取得し、機能プロバイダ情報テーブル４２３から機能プロバイダ情報を検索する。

Ｓ９０６において、ワークフロー処理部４３０は機能プロバイダ検索結果を受け取り、検索条件に一致する機能プロバイダがあるかどうかをチェックする。Ｓ９０６において、ワークフロー処理部４３０は、検索結果に一致する機能プロバイダがあればＳ９０７へ処理を進める。ワークフロー処理部４３０は、検索に一致する機能プロバイダがなければ、Ｓ９１０に処理を進める。Ｓ９１０において、ワークフロー処理部４３０は、エラーを通知してワークフローの実行処理を終了する。

Ｓ９０７において、ワークフロー処理部４３０は、Ｓ９０５の検索結果として取得した機能プロバイダの事前確認処理を呼び出す。その際、ワークフロー処理部４３０は、Ａｃｔｉｏｎタグの子要素としてＰａｒａｍｅｔｅｒタグの定義に従って、機能プロバイダに入力を与える。
Ｓ９０８において、ワークフロー処理部４３０によって呼び出された機能プロバイダが、指示に従って処理を実行する。Ｓ９０９において、ワークフロー処理部４３０は呼び出した機能プロバイダの実行完了を待ち受ける。

Ｓ９１１において、ワークフロー処理部４３０は、Ｓ９０９で取得した事前確認の結果を確認し、事前確認がＮＧ、すなわち実行不可となった件数が０より多いか否かを判断する。ワークフロー処理部４３０が、ＮＧの件数が０より多いと判断した場合は、処理はＳ９１２に進み、事前確認処理結果エラーを通知して処理を終了する。

Ｓ９１３において、ワークフロー処理部４３０は、実行指示に対応するワークフロー定義ファイル４４０を再度読み込む。Ｓ９１４において、ワークフロー処理部４３０は、ＦＰタグから機能プロバイダを取得し、機能プロバイダ情報テーブルから機能プロバイダ情報を取得する。Ｓ９１５において、ワークフロー処理部４３０は、次に実行すべき機能プロバイダがあればＳ９１６へ進み、次に事前確認を実行すべき機能プロバイダがなければ（最後の機能プロバイダまで取得し終えたら）、処理はＳ９２２に進む。

Ｓ９１６において、ワークフロー処理部４３０はワークフロー定義ファイル４４０から処理対象となっているＦＰタグの子要素であるＡｃｔｉｏｎタグを実行順に１つ取り出す。ここで実行順とは、Ａｃｔｉｏｎタグのｎｏ要素に定義された数字の若い順を意味する。

Ｓ９１７において、ワークフロー処理部４３０は、次に処理すべきＡｃｔｉｏｎタグ７０６があればＳ９１８へ進み、次に処理すべきＡｃｔｉｏｎタグ７０６がなければ（最後のＡｃｔｉｏｎタグ７０６まで取得し終えたら）Ｓ９１４へ戻る。

９１８において、ワークフロー処理部４３０は、Ａｃｔｉｏｎタグの定義に従って、Ｓ９０５の検索結果として取得した機能プロバイダを呼び出す。その際、ワークフロー処理部４３０は、Ａｃｔｉｏｎタグの子要素としてＰａｒａｍｅｔｅｒタグまたはＩｎｐｕｔタグが定義されていれば、その定義に従って、機能プロバイダに入力を与える。例えば、ＡｃｔｉｏｎタグのＩｎｐｕｔタグはスキャンプロバイダの「ｄｏＳｃａｎ」呼び出しの入力に関する定義で、「Ｄｏｃｕｍｅｎｔ」をＩＤが「ｆｏｏ」のデータから受け取ることを示している。

ＩＤが「ｆｏｏ」のデータは、Ａｃｔｉｏｎタグ７０３のＯｕｔｐｕｔタグで定義したファイル取得プロバイダの「ｄｏＳｃａｎ」の出力データである。ゆえに、ワークフロー処理部４３０は、自身が保持している「ｄｏＳｃａｎ」の出力データを、「ｄｏＯＣＲ」の呼び出し時に入力データとして与える。Ｓ９１９において、ワークフロー処理部４３０によって呼び出された機能プロバイダが、指示に従って処理を実行する。Ｓ９２０において、ワークフロー処理部４３０は呼び出した機能プロバイダの実行完了を待ち受ける。

Ｓ９２０において、ワークフロー処理部４３０は、機能プロバイダの出力を、別の機能プロバイダの入力として使用できるようＨＤＤ２１４またはＲＡＭ２１３に保存する。例えば、Ａｃｔｉｏｎタグ７０３のＯｕｔｐｕｔタグはスキャンプロバイダの「ｄｏＳｃａｎ」呼び出しの出力に関する定義で、「ｄｏＳｃａｎ」の出力である「Ｄｏｃｕｍｅｎｔ」データを、ＩＤを「ｆｏｏ」として保存する。機能プロバイダの出力を保存したら、ワークフロー処理部４３０は次の機能プロバイダの定義を取得するために、Ｓ９１６へ処理を進める。

以上のように、前述の第実施形態において説明した手順により、複数の機能プロバイダを組み合わせて一連の処理として実行する手段および一連の処理の前に、ワークフロー処理部４３０が各機能プロバイダの事前確認処理を指示する。呼び出された機能プロバイダが、指示に応じて各機能プロバイダに応じた事前確認処理を実行し、その結果をワークフロー処理部４３０に送信する。そしてワークフロー処理部４３０が事前確認結果に実行不可が無ければ、ワークフローを実行する。これにより、アプリの構成変更が行われた場合でも、ユーザが再度お気に入り設定を行う手間を軽減することができる。これにより、ワークフローアプリと機能プロバイダが疎結合の構成であっても、機能プロバイダに事前確認処理を委譲することで、ユーザからワークフロー実行指示後、実際にジョブ実行する前に事前条件を確認することが可能になる。
〔第２実施形態〕
次に、本発明に係る第２実施形態について説明する。第２実施形態において、機能プロバイダの形態によって、ユーザに対して表示したい事前確認結果の形式を変更したい場合がある。

そこで、本実施形態では、機能プロバイダから受信した事前確認結果に応じて、事前確認結果を変更する処理の例を説明する。なお、特に断らない限り、本実施形態について、第１実施形態と同一の番号のブロック図、シーケンス図、フローチャートや処理は、それぞれ第１実施形態の同一番号のブロック図、シーケンス図、フローチャートや処理と同一のものである。
図１０は、本実施形態におけるＭＦＰ１０１上で、機能プロバイダ４１１〜４１７からワークフロー処理部４３０に返却される事前確認結果情報を示す図である。

図１０の（Ａ）において、事前確認結果情報は、後述の図において、各機能プロバイダからワークフロー処理部４３０に対して返却される事前確認結果情報である。図１０の事前確認結果情報は、機能プロバイダインターフェース情報４２４の各機能プロバイダインターフェースの事前確認処理を表す「ｐｒｅＣｈｅｃｋ」メソッドの返し値である「ＣｈｅｃｋＲｅｓｕｌｔ」を表す。

本実施形態では、事前確認結果情報はパラメータ形式となっているが、ＣＳＶ、ＸＭＬその他フォーマットの形式のファイルであってもよい。Ｒｅｓｕｌｔは、事前確認結果のうち、確認結果である実行可能（ＯＫ）または実行不可（ＮＧ）であることを示す。本実施形態では、事前確認結果の属性は、メッセージ属性（Ｍｅｓｓａｇｅ）、メソッド属性（Ｍｅｔｈｏｄ）、ＵＲＬ属性（ＵＲＬ）に従い通知されるものとする。

Ｍｅｓｓａｇｅは、事前確認結果のうちメッセージ文字列を示す。Ｍｅｔｈｏｄは、事前確認結果のうち、機能プロバイダが事前確認結果を表示させるためのメソッドをもっていた場合に、事前確認結果を表示する処理を指示するためのメソッド名を示す。ＵＲＬは、事前確認結果のうち、機能プロバイダが事前確認結果を示すためのＷｅｂページがある場合、Ｗｅｂページを表示させるためのＵＲＬを示す。

図１０の（Ａ）は、事前確認情報のうち、確認結果とメッセージ文字列のみが含まれている例を示す。機能プロバイダにＵＩが無い場合、例えば組込ＯＣＲプロバイダ４１２の場合、図１０の（Ａ）のようなパターンとなる。

図１０の（Ｂ）は、事前確認情報のうち、確認結果、メッセージ文字列、メソッド名が含まれている例を示す。機能プロバイダにＵＩが有る場合、例えば標準スキャンプロバイダ４１１、ＳＭＢ取得プロバイダ４１４、Ｂｏｘ取得プロバイダ４１５、ＦＡＸ送信プロバイダ４１６、メール送信プロバイダ４１７の場合、図１０の（Ｂ）のようなパターンとなる。

図１０の（Ｃ）は、事前確認情報のうち、確認結果、メッセージ文字列、ＵＲＬが含まれている例を示す。機能プロバイダにＵＩは無いが、表示用のＷｅｂページが有る場合、例えばＷｅｂ ＯＣＲプロバイダ４１３の場合、図１０の（Ｃ）のようなパターンとなる。

図１１は、ＭＦＰ１０１内で管理している事前確認結果画面の例を示す図である。本例は、ワークフローで使用する機能プロバイダから応答される事前確認結果に従うエラー通知の詳細通知画面であって、本実施形態では、操作部の操作画面に表示する表示制御例である。

事前確認結果画面は、後述の図１６において、事前確認結果を表示するための画面である。事前確認結果画面は、ワークフロー処理部４３０において、機能プロバイダから受信した、図１０の事前確認結果情報に応じて、操作部２２０に表示する事前確認結果画面の一例である。

図１１の（Ａ）は、ワークフロー処理部４３０が、機能プロバイダから受信した事前確認結果情報が図の（Ａ）の場合に、操作部２２０に表示する事前確認結果画面である。機能プロバイダ名１１０１は、事前確認結果がＮＧとなった機能プロバイダ名を示す。メッセージ１１０２は、事前確認結果のメッセージ文字列を示す。ＯＫボタン１１０３は、事前確認結果の確認を終了する際に、ユーザによって押下されるボタンを示す。

図１１の（Ｂ）は、ワークフロー処理部４３０が、機能プロバイダから受信した事前確認結果情報が図１０の（Ｂ）の場合に、操作部に表示する事前確認結果画面である。機能プロバイダ名１１１１は、事前確認結果がＮＧとなった機能プロバイダ名を示す。メッセージ１１１２は、事前確認結果のメッセージ文字列を示す。詳細ボタン１１１３は、事前確認結果の詳細画面を機能プロバイダに表示させる場合に、ユーザによって押下されるボタンである。詳細ボタン１１１３がユーザによって押下された場合は、ワークフロー処理部４３０は、機能プロバイダに対して、図１０のｍｅｔｈｏｄタグで示された機能プロバイダのメソッドの実行を指示する。詳細ボタンが押下されると、後述の図１２の（Ａ）の詳細画面に遷移する。ＯＫボタン１１１４は、事前確認結果の確認を終了する際に、ユーザによって押下されるボタンを示す。

図１１の（Ｃ）は、ワークフロー処理部４３０が、機能プロバイダから受信した事前確認結果情報が図１０の（Ｃ）の場合に、操作部２２０に表示する事前確認結果画面である。機能プロバイダ名１１２１は、事前確認結果がＮＧとなった機能プロバイダ名を示す。メッセージ１１２２は、事前確認結果のメッセージ文字列を示す。詳細ボタン１１２３は、事前確認結果の詳細画面を機能プロバイダに表示させる場合に、ユーザによって押下されるボタンである。

詳細ボタン１１２３がユーザによって押下された場合は、ワークフロー処理部４３０は、図１０のＵＲＬタグ（取得先）で示されたＷｅｂページのＨＴＭＬを取得し、操作部２２０に表示する。詳細ボタン１１１３が押下されると、後述の図１２の（Ｂ）の詳細画面に遷移する。ＯＫボタン１１２４は、事前確認結果の確認を終了する際に、ユーザによって押下されるボタンを示す。
図１２は、図１に示したＭＦＰ１０１内で管理している詳細結果画面を示す図である。

図１２において、詳細結果画面１２００は、後述の図１６において、事前確認結果の詳細情報を表示するための画面である。事前確認結果画面１１００は、機能プロバイダ、または、ワークフロー処理部４３０において、図１０の事前確認結果情報に応じて、操作部２２０に表示する詳細結果画面の一例である。

図１２の（Ａ）は、ワークフロー処理部４３０が、機能プロバイダから受信した事前確認結果情報が図１０の（Ｂ）の場合で、図１１の（Ｂ）で詳細ボタンが押下された場合に、機能プロバイダによって操作部２２０に表示される詳細結果画面である。詳細結果画面１２０１は、ワークフロー処理部４３０が機能プロバイダから受信した事前確認結果情報が図１０の（Ｂ）であった場合に、ｍｅｔｈｏｄで示されたメソッドが実行された際に機能プロバイダが実行して表示する画面である。ＯＫボタン１２０２は、事前確認結果の確認を終了する際に、ユーザによって押下されるボタンを示す。

図１２の（Ｂ）は、ワークフロー処理部４３０が、機能プロバイダから受信した事前確認結果情報が図１０の（Ｃ）の場合に、図１１の（Ｃ）で詳細ボタン１１２３が押下された場合に、ワークフロー処理部４３０が操作部２２０に表示する詳細結果画面である。

詳細結果画面１２１１は、ワークフロー処理部４３０が機能プロバイダから受信した事前確認結果情報が図１０の（Ｃ）であった場合に、ＵＲＬで示されたＷｅｂページのＨＴＭＬを、ワークフロー処理部４３０が取得し表示する画面である。Ｗｅｂ画面１２１２は、ワークフロー処理部４３０がＵＲＬから取得したＨＴＭＬを埋め込んで表示する画面を示す。ＯＫボタン１２１３は、事前確認結果の確認を終了する際に、ユーザによって押下されるボタンを示す。
〔第２のシーケンス例〕

図１３は、本実施形態におけるＭＦＰ１０１上のワークフロー実行の流れを示したシーケンス図である。本例は、図８で示した処理のうち、事前確認結果に応じて事前確認結果表示処理を行う処理例である。なお、図１３の処理のうち、図８と同一の番号の処理は、それぞれ図８の処理と同一のものである。

図１３において、Ｓ１３０１は、ワークフロー処理部４３０が、Ｓ８０８、Ｓ８１１、Ｓ８１４、Ｓ８１７で、図１０の形式で事前確認結果情報を受信した際の処理である。Ｓ１３０１は、ワークフロー処理部４３０が、Ｓ８０８、Ｓ８１１、Ｓ８１４、Ｓ８１７で受信した事前確認結果情報に応じて、結果表示処理を行う。処理の詳細は図１５で説明する。

図１４は、本実施形態を示す情報処理装置の制御方法を説明するフローチャートである。本例は、ＭＦＰ１０１におけるワークフロー実行処理例である。各ステップは、ＭＦＰ１０１のＨＤＤ２１４に記憶されているプログラムを、ＣＰＵ２１１がＲＡＭ２１３に読み出し、解析、実行することで実現される。すなわち、図１４は、本実施形態におけるＭＦＰ１０１上で、図９のフローチャートで示した処理に対して、事前確認結果に応じて事前確認結果表示処理を行う処理の流れを示す。なお、図の処理のうち、図９と同一の番号の処理は、それぞれ図９の処理と同一のものである。

Ｓ１４０１は、ワークフロー処理部４３０が、Ｓ９０９で、図の形式で事前確認結果情報を受信した際の処理である。Ｓ１４０１は、ワークフロー処理部４３０が、Ｓ９０９で受信した事前確認結果情報に応じて、結果表示処理を行う。処理の詳細は図１５で説明する。

図１５は、本実施形態を示す情報処理装置の制御方法を説明するフローチャートである。本例は、ＭＦＰ１０１における、Ｓ１３０１、Ｓ１４０１の事前確認結果表示処理例である。なお、各ステップは、ＭＦＰ１０１のＨＤＤ２１４に記憶されているプログラムを、ＣＰＵ２１１がＲＡＭ２１３に読み出し、解析、実行することで実現される。

Ｓ１５０１において、ワークフロー処理部４３０が、変数ｉの値がＳ９０９で受信した事前確認結果の件数以下であるか否かを判断する。なお、変数ｉの初期値は０である。ワークフロー処理部４３０が変数ｉの値が事前確認結果の件数以下であると判断した場合は、処理はＳ１５０２に進み、そうではないと判断した場合は、処理はＳ１５１０に進む。
Ｓ１５０２において、ワークフロー処理部４３０が、Ｓ９０９で受信した事前確認結果情報のうちｉ番目の結果情報を取り出す。

Ｓ１５０３において、ワークフロー処理部４３０が取り出した事前確認結果の、Ｒｅｓｕｌｔ（結果）の値がＮＧ（実行不可）であるか否かを判断する。ワークフロー処理部４３０が取り出した事前確認結果のＲｅｓｕｌｔの値がＮＧであると判断した場合は、処理はＳ１５０４に進み、そうではない場合は、処理はＳ１５０９に進む。

Ｓ１５０４において、ワークフロー処理部４３０が取り出した事前確認結果の、Ｍｅｓｓａｇｅ（メッセージ文字列）の値が含まれているか否かを判断する。ワークフロー処理部４３０が、取り出した文字情報である事前確認結果のＭｅｓｓａｇｅの値が含まれていると判断した場合は、処理はＳ１５０５に進み、そうではないと判断した場合は、処理はＳ１５０６に進む。
Ｓ１５０５において、ワークフロー処理部４３０が、図１１の確認結果画面に対して、事前確認結果情報から取り出したＭｅｓｓａｇｅの値を追加する。

Ｓ１５０６において、ワークフロー処理部４３０が取り出した事前確認結果の、Ｍｅｔｈｏｄ（詳細画面のメソッド名）の値が含まれているか否かを判断する。ワークフロー処理部４３０が、取り出した事前確認結果のＭｅｔｈｏｄの値が含まれていると判断した場合は、処理はＳ１５０８に進み、そうではない場合は、処理はＳ１５０７に進む。

Ｓ１５０７において、ワークフロー処理部４３０が取り出した事前確認結果の、ＵＲＬ（詳細画面のＷｅｂページのＵＲＬ）の値が含まれているか否かを判断する。ワークフロー処理部４３０が、取り出した事前確認結果のＵＲＬの値が含まれていると判断した場合は、処理はＳ１５０８に進み、そうではない場合は、処理はＳ１５０９に進む。
Ｓ１５０８において、ワークフロー処理部４３０が、図１１の確認結果画面に対して、詳細ボタンを追加する。Ｓ１５０９において、ワークフロー処理部４３０が、変数ｉの値に１を加算し、処理はＳ１５０９に進む。

Ｓ１５１０においては、ワークフロー処理部４３０が、事前確認結果のＮＧ（実行不可）の件数が０よりも多いか否かを判断する。ワークフロー処理部４３０が、事前確認結果のＮＧ（実行不可）の件数が０よりも多いと判断した場合は、処理はＳ１５１１に進み、そうではない場合は、処理を終了する。
Ｓ１５１１においては、ワークフロー処理部４３０が事前確認結果画面を表示する処理を行う。処理の詳細は図１６で説明する。
図１５の処理の結果、ワークフロー処理部４３０が受信した事前確認結果情報が図１０の（Ａ）の場合には、図１１の（Ａ）のようなエラー内容であるメッセージ文字列１１０１を表示する事前確認結果画面１１１０が作成される。

図１５の処理の結果、ワークフロー処理部４３０が受信した事前確認結果情報が図１０の（Ｂ）の場合には、図１１の（Ｂ）のようなメッセージ文字列と詳細ボタンを表示する事前確認結果画面が作成される。図１５の処理の結果、ワークフロー処理部４３０が受信した事前確認結果情報が図１０の（Ｃ）の場合には、図１１の（Ｃ）のようなメッセージ文字列と詳細ボタンを表示する事前確認結果画面が作成される。

図１６は、本実施形態を示す情報処理装置の制御方法を説明するフローチャートである。本例は、ＭＦＰ１０１における、Ｓ１５１１の事前確認結果画面の表示処理の詳細例である。各ステップは、ＭＦＰ１０１のＨＤＤ２１４に記憶されているプログラムを、ＣＰＵ２１１がＲＡＭ２１３に読み出し、解析、実行することで実現される。
Ｓ１６０１において、ワークフロー処理部４３０が図１５で作成した事前確認結果画面を、操作部Ｉ／Ｆ２１５を通じて操作部２２０を表示制御することで表示する。

Ｓ１６０２において、ワークフロー処理部４３０が表示した事前確認結果画面１１００上で、ユーザによって詳細ボタンが押下されたか否かを判断する。ワークフロー処理部４３０が表示した事前確認結果画面１１００上で、ユーザによって詳細ボタンが押下されたと判断した場合は、処理はＳ１６０３に進み、そうではない場合はＳ１６１１に進む。

Ｓ１６０３において、ワークフロー処理部４３０がＳ１６０２で押下された詳細ボタンに対応する事前確認結果にＭｅｔｈｏｄが含まれているか否かを判断する。ワークフロー処理部４３０がＳ１６０２で押下された詳細ボタンに対応する事前確認結果にＭｅｔｈｏｄが含まれていると判断した場合は、処理は１６０４に進み、そうではない場合は、処理はＳ１６０７に進む。

Ｓ１６０４において、ワークフロー処理部４３０が事前確認結果に基づき、機能プロバイダに対してメソッドを実行指示する。すなわち、ワークフロー処理部４３０が、機能プロバイダの、事前確認結果のＭｅｔｈｏｄで示された詳細結果表示用のメソッドを実行指示する。なお、事前確認結果のＭｅｔｈｏｄは、通知されたエラー内容に従い、ユーザがエラー解除する操作指示情報に対応づけられている。

Ｓ１６０５において、ワークフロー処理部４３０からの指示に基づき、機能プロバイダが、事前確認結果のＭｅｔｈｏｄに対応する詳細結果表示用のメソッドを実行する。機能プロバイダの詳細結果表示処理によって、操作部２２０には図１２の（Ａ）の詳細結果画面１２０１のような画面が表示制御により表示される。そして、機能プロバイダがユーザによってＯＫボタン１２０２が押下されたことを確認すると、ワークフロー処理部４３０に対して処理完了を通知する。Ｓ１６０６において、ワークフロー処理部４３０が機能プロバイダの処理完了を待ち受ける。そして処理はＳ１６１０に進む。

Ｓ１６０７において、ワークフロー処理部４３０がＳ１６０２で押下された詳細ボタンに対応する事前確認結果にＵＲＬが含まれているか否かを判断する。ワークフロー処理部４３０がＳ１６０２で押下された詳細ボタンに対応する事前確認結果にＵＲＬが含まれていると判断した場合は、処理はＳ１６０８に進み、そうではない場合は、処理はＳ１６０２に進む。

Ｓ１６０８において、ワークフロー処理部４３０が、ネットワークＩ／Ｆ２１８を通じて、事前確認結果のＵＲＬに対応する詳細結果表示用のＷｅｂサーバ（例えばサーバ１０２）にアクセスし、ＵＲＬに対応するＨＴＭＬを取得する。

Ｓ１６０９において、ワークフロー処理部４３０が、Ｓ１６０８において取得したＨＴＭＬを埋め込んだ詳細結果画面を表示する。すなわち、ワークフロー処理部４３０は、図１２の（Ｂ）のように、詳細結果画面１２１１のＷｅｂページに対して、Ｓ１６０８で取得したＨＴＭＬを埋め込む。そして、ワークフロー処理部４３０は、操作部Ｉ／Ｆ２１５を通じて操作部２２０に、詳細結果画面を表示させる。

Ｓ１６１０において、ワークフロー処理部４３０は、Ｓ１６０９で表示させた詳細結果画面上のＯＫボタン１２１３又はＳ１６０５で表示された詳細結果画面上のＯＫボタンが押下されたか否かを判断する。ワークフロー処理部４３０は、Ｓ１６０９又はＳ１６０５で表示させた詳細結果画面上のＯＫボタン１２１３、１２０２が押下されたと判断した場合は、処理はＳ１６０２に進み、そうではない場合は、処理はＳ１６１０に戻る。

Ｓ１６１１において、ワークフロー処理部４３０が、事前確認結果画面１１００上でＯＫボタン１１０３、ＯＫボタン１１１４、ＯＫボタン１１２４のいずれかが押下されたか否かを判断する。ワークフロー処理部４３０が、事前確認結果画面上でＯＫボタン１１０３、ＯＫボタン１１１４、ＯＫボタン１１２４のいずれかが押下されたと判断した場合は、処理は終了し、そうではない場合は、処理はＳ１６０２に戻る。

以上、前述の第２実施形態において説明した手順により、機能プロバイダの実装形態に応じてワークフローアプリが表示手段を適切に判断することで、ユーザに対して、事前確認結果を適切に通知することができる。すなわち、機能プロバイダが事前確認結果としてメッセージ文字列のみ返す場合は、ワークフロー処理部４３０は、メッセージ文字列を表示する事前確認結果画面を表示する。機能プロバイダが事前確認結果としてメッセージ文字列と機能プロバイダの詳細結果画面表示用のメソッド名を返す場合は、ワークフロー処理部４３０は、メッセージ文字列と詳細ボタンを表示する事前確認結果画面を表示する。

さらにワークフロー処理部４３０は詳細ボタンが押下された際に、機能プロバイダの詳細結果画面表示用のメソッドを実行し、詳細結果画面表示処理を機能プロバイダに移譲する。さらに、機能プロバイダが事前確認結果としてメッセージ文字列と詳細結果画面を表すＷｅｂページのＵＲＬを返す場合は、ワークフロー処理部４３０は、メッセージ文字列と詳細ボタンを表示する事前確認結果画面を表示する。

さらに、ワークフロー処理部４３０は、詳細ボタンが押下された際に、ＵＲＬにアクセスして取得したＨＴＭＬを取得して、取得したＨＴＭＬを埋め込んだ詳細結果画面を表示する。これらにより、機能プロバイダの実装形態に応じてワークフローアプリが表示手段を適切に判断し、ユーザに対して、事前確認結果を適切に通知することができる。

本発明は、上述の実施形態の以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステムまたは装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサがプログラムを読み出し実行する処理でも実現可能である。また、以上の機能を実現する回路（例えばＡＳＩＣ）によっても実現可能である。

１０１ ＭＦＰ
１０２ サーバ

Claims (10)

1. 所定のジョブを実行する情報処理装置であって、
   特定の機能処理を実行する機能プロバイダを用いて所定のジョブワークフロー定義ファイルに記載されたワークフローを実行する実行手段と、
   前記所定のジョブを実行する前に、前記ワークフローで使用される各機能プロバイダに対して、機能プロバイダが正常に動作する状態であるかを確認する確認要求を行う要求手段と、
   前記要求手段による確認要求に対する各機能プロバイダから応答される事前確認結果にエラー通知が含まれているかどうかを判断する判断手段と、
   各機能プロバイダからの事前確認結果にエラー通知が含まれていると判断した場合、対応する機能プロバイダの事前確認結果を通知する通知手段と、
   を備えることを特徴とする情報処理装置。
2. 各機能プロバイダから応答される事前確認結果にエラー通知が含まれていないと判断した場合、前記実行手段は、特定の機能処理を実行する機能プロバイダを用いて所定のジョブワークフロー定義ファイルに記載されたワークフローを開始させることを特徴とする請求項１に記載の情報処理装置。
3. 前記通知手段は、
   各機能プロバイダから応答される事前確認結果にエラー通知が含まれていると判断した場合、エラー内容を解析して詳細通知画面を操作画面に表示する第１の表示制御手段を備えることを特徴とする請求項１に記載の情報処理装置。
4. 前記通知手段は、
   各機能プロバイダから応答される事前確認結果にエラー通知が含まれていると判断した場合、エラー内容で特定される取得先から詳細通知画面を取得する手段と、
   前記取得手段が取得した詳細通知画面を操作画面に表示する第２の表示制御手段を備えることを特徴とする請求項１に記載の情報処理装置。
5. 前記第１の表示制御手段は、前記事前確認結果に含まれる文字情報を用いて詳細通知画面を表示することを特徴とする請求項３に記載の情報処理装置。
6. 前記第２の表示制御手段は、前記事前確認結果にエラーを解除する操作指示情報が含まれている場合、当該操作指示情報を取得して表示するためのボタンを詳細通知画面に表示することを特徴とする請求項４に記載の情報処理装置。
7. 前記第２の表示制御手段は、前記事前確認結果の取得先を特定する情報が含まれている場合、当該取得先を特定する情報を表示するためのボタンを詳細通知画面に表示することを特徴とする請求項４に記載の情報処理装置。
8. 前記事前確認結果の属性は、メッセージ属性、メソッド属性、ＵＲＬ属性であることを特徴とする請求項１に記載の情報処理装置。
9. 所定のジョブを実行する情報処理装置の制御方法であって、
   特定の機能処理を実行する機能プロバイダを用いて所定のジョブワークフロー定義ファイルに記載されたワークフローを実行する実行工程と、
   前記所定のジョブを実行する前に、前記ワークフローで使用される各機能プロバイダに対して、機能プロバイダが正常に動作する状態であるかを確認する確認要求を行う要求工程と、
   前記要求工程による確認要求に対する各機能プロバイダから応答される事前確認結果にエラー通知が含まれているかどうかを判断する判断工程と、
   各機能プロバイダからの事前確認結果にエラー通知が含まれていると判断した場合、対応する機能プロバイダの事前確認結果を通知する通知工程と、
   を備えることを特徴とする情報処理装置の制御方法。
10. 請求項９に記載の情報処理装置の制御方法をコンピュータに実行させることを特徴とするプログラム。

Images