(57)【要約】【課題】電子申請において、データ連携のために、電子申請システムから申請データを他システムに送信する場合に、電子申請システムが送信先の他システムのインターフェースに応じて送信手順を準備する必要がある。【解決手段】実処理を行うデータ送信前処理実装部と、データ送信処理実装部と、データ送信後処理実装部として使用するプログラム名称を電子申請システムの起動時やデータ送信要求発生時に解決する手段を有し、データ連携する地方自治体等の既存システムが提供するデータ連携インターフェースに合わせて実処理を行うデータ送信前処理実装部とデータ送信処理実装部とデータ送信後処理実装部に相当するプログラムを差し替える、又は、追加する手段を有するデータ送信機能を構成する。【選択図】  図２
2005107774.tif 000002
【特許請求の範囲】
【請求項１】
電子申請を受け付けるシステムと連携する複数のシステムからなる電子申請システムにおいて、地方自治体等に存在する既存システムへのデータ送信要求を受け付けるデータ送信要求受付部と、
データ送信要求受付部からの要求でデータ送信を実施するために送信動作を制御するためのデータ送信制御部と、該データ送信制御部に制御されデータ送信の前処理を行うデータ送信前処理部と、該データ送信制御部に制御されるデータ送信を行うデータ送信部と、該データ送信制御部に制御されるデータ送信の後処理を行うデータ送信後処理部と、
該データ送信前処理部と該データ送信部と該データ送信後処理部で実処理を行うために使用されるプログラムのプログラム名称を管理する処理実装定義部と、
該データ送信前処理部の実処理を行うデータ送信前処理実装部と、該データ送信部の実処理を行うデータ送信処理実装部と、該データ送信後処理部の実処理を行うデータ送信後処理実装部と、
該データ送信前処理実装部と該データ送信処理実装部と該データ送信後処理実装部として使用するプログラム名称を電子申請システムの起動時又はデータ送信要求発生時に解決する手段を有し、
データ連携する前記複数のシステムが提供するそれぞれのデータ連携インターフェースに合わせて実処理を行う該データ送信前処理実装部と該データ送信処理実装部と該データ送信後処理実装部に相当するロード対象のプログラムを差し替える手段を有することを特徴とした電子申請システム。
【請求項２】
請求項１記載のプログラムを差し替える手段に変わりロード対象のプログラムを追加する手段を有することを特徴とする電子申請システム。
【請求項３】
請求項１記載のプログラム名称解決手段は、データ送信起動時に該処理実装定義部から送信前処理実装部、送信処理実装部、送信後処理実装部のぞれぞれのプログラム名称を取得することを特徴とする電子申請システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、既存の業務システムとの連携する電子申請システムに関する。
【背景技術】
【０００２】
従来、住民票、印鑑証明書、などの発行申請を地方自治体で受け付ける場合の処理は、役所内の受付窓口で申請書用紙に必要事項を記入する方法で申請手続きを行っている。しかし、何等かの仕事を持っている住民にとっては、休日以外はなかなか申請するための時間がとれないのが実情である。
【０００３】
そのような不便を解決するため、電子政府の一環として、インターネットによる申請を実現する電子申請システムの構築が、中央官庁を始め、いくつかの地方自治体で行われている。しかし、全国の全自治体が、それぞれ個別に電子申請システムを立ち上げることは、コストの観点から現実的ではないという意見がある。
そのための１つの解決策として、共同利用センタに電子申請システムを構築し、近隣の地方自治体が共同利用する形態が考えられる。
【０００４】
この場合、ひとつの電子申請システムが、複数の地方自治体側に存在する既存システムに対し、申請データを送信する必要性が生じる。
複数の地方自治体側に存在する既存システムのデータ連携インターフェースは、通常、システムごとに異なることが想定されるため、共同利用センタ側の電子申請システムが、複数のデータ送信インターフェースを準備する必要がある。
また、共同利用センタに接続する地方自治体が増加した場合にも柔軟にデータ送信インターフェースを追加し対応できる必要がある。
【０００５】
このような要件に対応するシステムとして、特許文献１に示すようなシステムが提案されている。本公知例は、ゲートウェイ装置を用いて、携帯電話等の端末から通信キャリア網を介して行政サービスを提供するものであり、住民と行政間のデータフォーマットを変換する機能を備えている。
【０００６】
【特許文献１】特開２００１−１４２９５６号公報
【発明の開示】
【発明が解決しようとする課題】
【０００７】
上記従来のシステムでは、住民と行政間のデータフォーマットを変換する機能を持つものの、行政側が外部ネットワーク向けに公開している行政サービスに対する通信プロトコルの変換を行うものではなく、ゲートウェイ装置と行政サービスを提供するシステムとの連携には、地方自治体側に既存のシステムとは別にエージェント機能部を設置して対応している。
したがってこの方式では、既存システムが外部ネットワーク向けにサービスを公開しているにもかかわらず、ゲートウェイ装置と通信するためのエージェント機能を各地方自治体に別途設置しなければならないという問題がある。
【０００８】
本発明の目的は、係る問題点を解決して、電子申請において複数のデータ送信インターフェースに対応し、かつ、柔軟にデータ送信インターフェースを追加できる他システムとのデータ連携方法を提供することにある。
【課題を解決するための手段】
【０００９】
上記課題を解決するため、本発明では、電子申請システムと、地方自治体の既存システムとをデータ連携する構成において、地方自治体等に存在する既存システムへのデータ送信要求を受け付けるデータ送信要求受付部と、データ送信要求受付部からの要求でデータ送信を実施するために送信動作を制御するためのデータ送信制御部と、データ送信制御部に制御されデータ送信の前処理を行うデータ送信前処理部と、データ送信を行うデータ送信部と、データ送信の後処理を行うデータ送信後処理部と、データ送信前処理部とデータ送信部とデータ送信後処理部で使用されるプログラム名称を管理する処理実装定義部と、データ送信前処理部とデータ送信部とデータ送信後処理部のそれぞれの実処理を行うデータ送信前処理実装部とデータ送信処理実装部とデータ送信後処理実装部から構成され、実処理を行うデータ送信前処理実装部と、データ送信処理実装部と、データ送信後処理実装部として使用するプログラム名称を電子申請システムの起動時やデータ送信要求発生時に解決する手段を有し、データ連携する地方自治体等の既存システムが提供するデータ連携インターフェースに合わせて実処理を行うデータ送信前処理実装部とデータ送信処理実装部とデータ送信後処理実装部に相当するプログラムを差し替える、又は、追加する手段を有するデータ送信機能を構成する。
このとき、電子申請システムが共同利用センタに構築されているか、各地方自治体個別に構築するかは問わない。
【００１０】
電子申請システムは、利用者から送信された申請データを受付処理し、データ送信要求受付部により地方自治体等に存在する既存システムへのデータ送信要求を受けて、データ送信制御部により申請データを送信する。この際インターフェースの相異を解決しないとデータの送信ができないので、電子申請システムの起動時又はデータ送信要求発生時に、処理実装定義部からプログラム名称を取得し、データ送信前処理部に対応するデータ送信前処理実装部、データ送信処理部に対応するデータ送信処理実装部、データ送信後処理部に対応するデータ送信後処理実装部によりプログラム名称解決処理を行う。プログラム名称解決処理済後、以下のようにデータ送信処理を行う。データ送信制御部がデータ送信前処理部のデータ送信前処理実装部を呼び出して実行し、実行の結果が成功であればデータ送信処理のデータ送信処理実装部を呼び出して実行し、実行の結果が成功であればデータ送信後処理のデータ送信後処理実装部を呼び出して実行する。実行の結果が成功であれば正常終了する。
【００１１】
また、本発明の実施例としての電子申請システムが共同利用型の場合は、共同利用センタに接続するサイトの増加に対しても低コストで柔軟に対応できるという効果を得ることが可能である。
【発明の効果】
【００１２】
以上のように本発明によれば、共同利用センタに接続する各地方自治体等のサイトで、電子申請システムが連携する既存システムがもつデータ連携インターフェースが異なる場合や、電子申請システムをパッケージ製品化する際に、当該パッケージが適用される地方自治体のデータ連携が必要な既存システムのデータ連携インターフェースが特定できない場合でも、メッセージパラメタ等のインターフェースの差異を電子申請システム側で吸収することが出来る。それにより、既存システム側の修正を回避できる。
【発明を実施するための最良の形態】
【００１３】
以下、本発明の実施の形態を、図面により詳細に説明する。図１は、本発明の一実施例を示す電子申請システムの全体構成図である。図１において、１はインターネット２に接続され、ＷＥＢブラウザ等が動作する利用者端末であり、通常、パーソナルコンピュータ（ＰＣ）や、携帯電話、ＰＤＡ等である。利用者（住民・企業の申請者）は、この利用者端末を使用して申請書などのデータを入力する。３は利用者からの申請を受付け、処理する電子申請システムで、４の申請受付機能、５の審査機能、６のデータ送信機能から構成される。また、電子申請システム３は、ネットワーク７を介して、地方自治体などの内部にある、職員端末８や、既存システム９と接続する。このとき、ネットワーク７は、電子申請システムが共同利用センタに配置される場合は、ＬＧＷＡＮであり、ある地方自治体単独に構成される場合はＬＡＮに相当する。審査端末８は、ネットワーク７を介して電子申請システム３内の審査機能５を利用して、職員端末に表示された申請データの審査や、審査後の申請データを既存システム９に送信させるために、データ送信機能６にデータ送信要求を発行する。また、データ送信機能６に対する送信要求イベントは、職員端末８からの操作のほかに、タイマ監視によるイベントでも対応可能である。１０は、利用者からの申請データを一時的に格納するデータベースシステム等の記憶装置であり、申請受付機能４、審査機能５、データ送信機能６が共用する。
【００１４】
図２は、図１のデータ送信機能６の内部構成である。職員端末８や、タイマ監視によるデータ送信要求イベントは、データ送信要求受信部６１で受信される。データ送信要求受信部６１は、イベントを検知すると、データ送信制御部６２を起動する。データ送信制御部６２は、データ送信要求受信部６１から起動されると、データ送信前処理部６３、データ送信処理部６４、データ送信後処理部６５を順次呼出し、実行する。データ送信前処理部６３、データ送信処理部６４、データ送信後処理部６５は、それぞれ、実行時、又はデータ送信機能６の起動時に、処理実装定義部６６によって、実際に動作するプログラム名称を解決しており、データ送信制御部６２からの実行要求時に、解決済みのプログラム名称を元に定義されたプログラムを起動する。
【００１５】
処理実装定義部６６は、データ送信前処理部６３に対応するデータ送信前処理実装部６７、データ送信処理部６４に対応するデータ送信処理実装部６８、データ送信後処理部６５に対応したデータ送信後処理実装部６９、それぞれの関連、名称を管理しており、データ送信前処理部６３、データ送信処理部６４、データ送信後処理部６５の要求に応じて対応する実装部のプログラム名称を回答する。処理実装定義部６６において、各部位のプログラム名称は、プログラム名称管理部６６１において管理されており、通常、DBMSや、XML等のテキストファイル等で構成される。データ送信前処理実装部６７は、メッセージパラメタ生成部６７１とユーザ任意処理部６７２から構成される。
【００１６】
メッセージパラメタ生成部６７１は、データ送信処理実装部６８で実際に使用される他システム連携用プログラムの呼出し引数を生成し、データ送信処理実装部６８に引き継ぐ。ユーザ任意処理部６７２は、パラメタ生成後に、ユーザ任意のフォーマットによるログ出力や、メッセージ送信の状態を管理していれば、状態を更新する等の、データ送信機能６を利用するユーザに特化した処理を記述することが可能な部分である。
【００１７】
データ送信処理実装部６８は、他システムとデータ連携するための実際の通信処理が記述されている部分であり、データ送信前処理実装部６７のメッセージパラメタ生成部６７１で生成されたパラメタを元に、他システム連携処理を実行する。実行結果はデータ送信後処理実装部６９に引き継ぐ。データ送信後処理実装部６９は、送信結果確認部６９１とユーザ任意処理部６９２から構成される。送信結果確認部６９１は、データ送信処理実装部６８の実行結果を受け取り、結果を解析し、送信成功又は送信失敗に対応して処理を決着する。
【００１８】
ユーザ任意処理部６９２は、処理結果決着時にユーザ任意のフォーマットによるログ出力や、独自の再送処理等の、データ送信機能６を利用するユーザに特化した処理を記述することが可能な部分である。
【００１９】
図３は、プログラム名称管理部６６１の管理情報の構成例であり、プログラム名称を解決すべき各実装部の名称を示すセクション名６６１１と、各実装部で、データ送信実行時に使用されるプログラム名称を示すプログラム名称６６１２から構成されている。プログラム名称６６１２に定義されたプログラム名称を元に、実行プログラムを確定するため、各セクションに、地方自治体等の本システム適用サイトに合わせた機能を実装したプログラム名称を定義することで、柔軟な対応が可能になる。本構成例では、各セクションに１つの実プログラムを割り当てるようになっているが、プログラム名称６６１２のデータ構造を配列にすることにより、各セクションに複数の実プログラムを割り当てる構成にすることも可能である。
【００２０】
次に、本実施例の動作について説明する。
図４は、処理実装定義部６６を用いた、データ送信前処理部６３に対応するデータ送信前処理実装部６７、データ送信処理部６４に対応するデータ送信処理実装部６８、データ送信後処理部６５に対応したデータ送信後処理実装部６９のプログラム名称解決処理のフローチャートである。図４の処理は、前述した通り、データ送信機能６の起動時に実施してあらかじめ各実装プログラム名を解決しておくこともできるが、実行時にプログラム名を毎回確認、解決する方法でも実現可能である。また、各実装プログラム名を複数定義することを可能にすることも出来る。ここでは、起動時にそれぞれの実装プログラム名称を1つずつ解決する方法を記述する。
【００２１】
図４において、まず、データ送信機能６が起動されると、データ送信前処理部６３が、処理実装定義部６６より、データ送信前処理実装部６７のプログラム名称を取得する（S１０１）。その結果、プログラム名称が取得できたかどうか判定する（S１０２）。プログラム名称が取得でき、値があった場合は、得られた値を元にプログラムであるデータ送信前処理実装部６７をロードする（S１０３）。プログラムのロード成否を判定し（S１０４）、ロードに失敗した場合、メッセージを出し異常終了する。ここで、データ送信前処理実装部のプログラム名称は必須にするという方式をとり、プログラム名称の取得結果の判定後の処理を簡略化させることも可能である。
【００２２】
このとき、本システムの適用サイトに固有なデータ送信前処理が存在しない場合は、データ送信前処理実装部に対応するプログラムは、何も実行しないプログラムとして実装される。次にデータ送信処理部６４が、処理実装定義部６６より、データ送信処理実装部６８のプログラム名称を取得する（S１０５）。通常、データ連携において、データ送信処理実装部６８が存在しない、又は処理がないことはあり得ない。
【００２３】
そこで、プログラム名称の取得結果を判定し（S１０６）、取得失敗、又は値無しの場合、メッセージを出し異常終了する。プログラム名称が取得できた場合、得られた値を元にプログラムであるデータ送信処理実装部６８をロードする（S１０７）。プログラムのロード成否を判定し（S１０８）、ロードに失敗した場合、メッセージを出し異常終了する。次にデータ送信後処理部６５が、データ送信後処理実装部６９のプログラム名称を取得する（S１０９）。
【００２４】
その結果、プログラム名称が取得できたかどうか判定する（S１１０）。プログラム名称が取得でき、値があった場合は、得られた値を元にプログラムであるデータ送信後処理実装部６９をロードする（S１１１）。プログラムのロード成否を判定し（S１１２）、ロードに失敗した場合、メッセージを出し異常終了する。ここで、データ送信後処理実装部のプログラム名称は必須にするという方式をとり、プログラム名称の取得結果の判定後の処理を簡略化させることも可能である。
【００２５】
このとき、本システムの適用サイトに固有なデータ送信後処理が存在しない場合は、データ送信後処理実装部に対応するプログラムは、何も実行しないプログラムとして実装される。
ここまでが正常終了することで、データ送信機能６が正常に起動する。
先述したが、この処理を起動時ではなく、データ送信の実行時に毎回行うことも可能であるが、起動時にプログラム名称解決、対象プログラムのロードを実行しておくことにより、データ送信時における名称解決に係る処理を省略でき性能向上に寄与できる。
【００２６】
次に実行時の処理フローを説明する。
図５は、データ送信実行時のデータ送信制御部６２の処理を示すフローチャートである。データ送信制御部６２は、データ受信部６１より呼び出されると、まず、データ送信前処理部６３を呼び出す（S２０１）。データ送信前処理部６３は、名称解決済み、ロード済みのデータ送信前処理実装部６７を呼出し、実行する。そして、呼出し、実行の結果を判定し（S２０２）、成功であれば、データ送信処理部６４を呼び出す（S２０３）。データ送信処理部６４は、名称解決済み、ロード済みのデータ送信処理実装部６８を呼出し、実行する。そして、呼出し、実行の結果を判定し（S２０４）、成功であれば、データ送信後処理部６５を呼び出す（S２０５）。
【００２７】
データ送信後処理部６５は、名称解決済み、ロード済みのデータ送信後処理実装部６９を呼出し、実行する。そして、呼出し、実行の結果を判定し（S２０６）、成功であれば正常終了とする。各判定処理において、エラーを検出すれば、メッセージを出し異常終了する。
【００２８】
図６は、データ送信前処理実装部６７の処理を示すフローチャートである。データ送信前処理実装部６７は、データ送信前処理部６３から呼び出されると、まず、データ連携先の他システムが公開しているインターフェースに準じたメッセージパラメタを生成する（S２０１１）。生成結果を判定し（S２０１２）、生成に成功すれば、固有フォーマットによるログ出力や、管理しているデータ送信の状態更新等、本システムの適用ユーザ固有の処理を実行する（S２０１３）。このユーザ任意処理の実行結果を判定し（S２０１４）、成功すれば正常終了とし、生成したメッセージパラメタを、データ送信処理部６４、データ送信処理実装部６８に引き継ぐ。各判定処理において、エラーを検出すれば、メッセージを出力し異常終了する。
【００２９】
図７は、データ送信処理実装部６８の処理を示すフローチャートである。データ送信処理実装部６８は、データ送信処理部６４から呼び出されると、データ連携先の他システムが公開しているインターフェースに順じて、データ連携を実行する（S２０３１）。データ連携の実行結果を判定し（S２０３２）、他システム側のインターフェース呼出しに成功していれば正常終了とし、呼出し結果をデータ送信後処理部６５、データ送信後処理実装部６９に引き継ぐ。インターフェース呼出しに失敗していれば、メッセージを出力し異常終了する。なお、呼出し失敗という事象も含めて呼出し結果とし、データ送信後処理部６５、データ送信後処理実装部６９に引き継ぐ方式も可能である。
【００３０】
図８は、データ送信後処理実装部６９の処理を示すフローチャートである。データ送信後処理実装部６９は、データ送信後処理部６５から呼び出されると、まず、データ連携先の他システムを呼び出した結果を解析する（S２０５１）。呼出し結果解析の結果を判定し（S２０５２）、確認に成功し、業務的にも成功であれば、処理結果フラグを”成功”に（S２０５３）、確認に失敗、又は確認は成功したが業務的に失敗であれば、処理結果フラグを”失敗”に設定し（S２０５４）、固有フォーマットによるログ出力や、管理しているデータ送信の状態更新等、本システムの適用ユーザ固有の処理を実行する（S２０５５）。このユーザ任意処理の実行結果を判定し（S２０５６）、任意処理が成功し、かつ処理結果フラグが”成功”であれば正常終了とし、任意処理が失敗か、又は任意処理が成功しても処理結果フラグが”失敗”であれば、メッセージを出力し異常終了する。
【００３１】
以上のように本実施例によれば、データ送信処理の実装部分をデータ送信機能から分離しているので、データ送信機能のメインロジックや、データ送信機能を利用している申請受付機能や審査機能を変更せずに、各地方自治体内に存在する他システムとのインターフェースに合致した実装部分のみを追加するだけでデータ連携を実現することが出来るため、電子申請システム本体への影響を回避でき、電子申請システムが共同利用センタ利用される場合は、参加する地方自治体ごとの柔軟なデータ連携を容易に実現できる。
【図面の簡単な説明】
【００３２】
【図１】本発明の一実施例を示す申請受付処理システムの全体構成図である。
【図２】図１におけるデータ送信機能の機能構成図である。
【図３】図２におけるプログラム名称管理部の一実施例を示すデータ構成図である。
【図４】図２における各実装部のプログラム名称を解決する処理の動作フローチャートである。
【図５】図２におけるデータ送信制御部の動作フローチャートである。
【図６】図２におけるデータ送信前処理実装部の動作フローチャートである。
【図７】図２におけるデータ送信処理実装部の動作フローチャートである。
【図８】図２におけるデータ送信後処理実装部の動作フローチャートである。
【符号の説明】
【００３３】
１…利用者端末、２…インターネット等のネットワーク、３…電子申請システム、４…申請受付機能、５…審査機能、６…データ送信機能、７…ＬＧＷＡＮ等のネットワーク、８…職員端末、９…各地方自治体の既存の他システム、１０…申請データ記憶装置、６１…データ送信要求受信部、６２…データ送信制御部、６３…データ送信前処理部、６４…データ送信処理部、６５…データ送信後処理部、６６…処理実装定義部、６６１…プログラム名称管理部、６７…データ送信前処理実装部、６７１…メッセージパラメタ生成部、６７２…ユーザ任意処理（前処理）、６８データ送信処理実装部、６９…データ送信後処理実装部、６９１…送信結果確認部、６９２…ユーザ任意処理（後処理）
【図１】
2005107774.tif 000003
【図２】
2005107774.tif 000004
【図３】
2005107774.tif 000005
【図４】
2005107774.tif 000006
【図５】
2005107774.tif 000007
【図６】
2005107774.tif 000008
【図７】
2005107774.tif 000009
【図８】
2005107774.tif 000010