(57)【要約】【課題】  アプリケーション間の連携状態を簡単に把握できるアプリケーション連携システムを提供する。【解決手段】  複数のアプリケーションが共通に利用する統合データベースによって管理された連携用ＡＰＩを作成し、定義する。連携用ＡＰＩは、統合データベースにデータを書き込む主幹ＡＰＩと、統合データベースからデータを読み込む利用ＡＰＩとに分類され管理される。アプリケーションは、他のアプリケーションと連携処理を行う場合には、連携用ＡＰＩを用いる。アプリケーションのプログラム内では、連携用ＡＰＩを呼び出し、他のアプリケーションとの連携処理を行う。連携用ＡＰＩは、使用されるたびにログを記録するので、アプリケーションの連携関係を、このログを用いて、自動で調べることが出来る。【選択図】図１
2006277403.tif 000002
【特許請求の範囲】
【請求項１】
複数のアプリケーションが、共通に設けられたデータベースのデータを用いて、連携処理を行う統合システムにおけるアプリケーションの連携方法であって、
複数のアプリケーションに対して定められた形式のアプリケーション間の連携インターフェースを提供し、アプリケーションによって実行される度にどのアプリケーションによってどのように使用されたかのログを記録するインターフェース手段を設け、
連携処理を行う場合、アプリケーションは連携しようとする他のアプリケーションに対応するインターフェース手段を実行し、
記録されたログからアプリケーション間の連携状態を取得する
ことを特徴とする連携方法をコンピュータに実現させるプログラム。
【請求項２】
前記インターフェース手段は、連携先のアプリケーションの処理結果を前記データベースに入力する入力インターフェースと、連携先のアプリケーションに入力するために該データベースからデータを読み出す出力インターフェースとに分類されることを特徴とする請求項１に記載のプログラム。
【請求項３】
アプリケーションの連携関係を図に表現することを特徴とする請求項１に記載のプログラム。
【請求項４】
アプリケーションの連携による処理の負荷を図に表現することを特徴とする請求項３に記載のプログラム。
【請求項５】
前記連携関係を表現した図上で、アプリケーションの連携システムをドラッグすることにより、該アプリケーションの連携システムに使用されるデータを前記データベースとは異なるデータベースに格納することを特徴とする請求項３に記載のプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数のアプリケーションを連携させて使用する統合システムに関する。
【背景技術】
【０００２】
異なるアプリケーションを複数連携して各業務を効率良く行う統合システムがある。統合システムにおいては、複数のアプリケーションが１つの統合データベースに格納されたデータを共有し、あるアプリケーションが統合データベースからデータを読み込み、処理した後にデータを統合データベースに書き込む。アプリケーション同士は、互いに統合データベースを介してデータをやり取りし、連携して、１つの業務を実行するようになっている。その連携の手法は、連携したいアプリケーション間（あるデータＡが欲しいアプリケーションとデータＡを持っているアプリケーション間）で個別に連携インターフェースプログラムを作成し、各々のアプリケーション内で実行することでデータ連携を可能にしている。
【０００３】
したがって、連携状態を把握するには、個々の連携時の設計書を元にどのように連携されているかを解析して調査する必要がある。アプリケーション間連携を構築した時の設計書に誤りや設計書自体が無い場合は、連携プログラムを解析する必要がある。 
【発明の開示】
【発明が解決しようとする課題】
【０００４】
上記のような従来の連携システムにおいては、以下のような問題がある。
（１）あるアプリケーションを修正・変更する場合、どのアプリケーションとアプリケーションが連携しているかが正確に分からない。
（２）あるアプリケーションを変更した場合、その影響範囲が分からない。
（３）連携関係を把握するのに膨大な時間やコストが発生する。
（４）システム拡張や変更が柔軟かつスピーディに行えない。
【０００５】
したがって、連携中のアプリケーションとデータがどのように連携（どのアプリケーションとどのアプリケーションが関係）しているかを早く正確に検査する仕組みを確立することが望まれている。また、アプリケーション間の連携データ項目の把握と連携利用頻度（負荷）状態を把握することも望まれる。
【０００６】
本発明の課題は、アプリケーション間の連携状態を簡単に把握できるアプリケーション連携システムを提供することである。
【課題を解決するための手段】
【０００７】
本発明の統合システムは、複数のアプリケーションが、共通に設けられたデータベースのデータを用いて、連携処理を行う統合システムにおけるアプリケーションの連携方法であって、複数のアプリケーションに対して定められた形式のアプリケーション間の連携インターフェースを提供し、アプリケーションによって実行される度にどのアプリケーションによってどのように使用されたかのログを記録するインターフェース手段を設け、連携処理を行う場合、アプリケーションは連携しようとする他のアプリケーションに対応するインターフェース手段を実行し、記録されたログからアプリケーション間の連携状態を取得することを特徴とする連携方法をコンピュータに実現させる。
【発明の効果】
【０００８】
本発明によれば、アプリケーション間の連携状態を簡単に把握することの出来るアプリケーション連携システムを構築することが出来る。
【発明を実施するための最良の形態】
【０００９】
本発明の実施形態では、以下を実現する。
（１）連携しようとするアプリケーション同士では直接データのやり取りを行わず、中間の統合データベースAPI（Application Program Interface）を介して行う。
（２）アプリケーション間連携で使う全てのAPIを統合管理する。どのアプリケーションで何のAPIを使っているかを把握するのに、APIから適時利用ログを吐き出す仕組みを設け、そのログを集計・分析することで、正確な連携図をリアルタイムに自動作成する。
【００１０】
すなわち、連携するアプリケーション間では直接連携（直接データやり取り）しないで、統合データベースで一元管理するＡＰＩを介して連携する。ＡＰＩがどのアプリケーションで使われているか追跡する仕組みを設ける。また、ＡＰＩ利用履歴テーブルを分析／集計することで、アプリケーション間の連携図を自動作成する（アプリケーション連携図）。アプリ連携図により、どのアプリケーションとアプリケーションが連携され、どんなデータ項目が どの頻度（負荷）でやり取りされているかを把握できるようにする。
【００１１】
以上により、
（１）アプリケーション連携システムの設計・開発担当者がいなくても、システム全体のアプリ連携状 態を正確に把握することができる。
（２）システムの拡張や変更を、リスク（調査の工数大，心理面・・の不安）無しに行うことができ、柔軟に対応することができる。
（３）アプリケーション連携状態の把握に限らず、アプリケーションの使われ方も追跡把握することができる。
（４）システム全体の利用傾向を分析できる。
という効果を有する。
【００１２】
図１は、本発明の実施形態の構成及び動作を説明する図である。
まず、１）に示されるように、本発明の実施形態のＡＰＩに登録するアプリケーションの名前と、その識別名を登録するアプリ識別テーブルを設ける。次に、アプリケーションの連携用ＡＰＩを管理するために連携用ＡＰＩ管理テーブル１１を設ける。連携用ＡＰＩ管理テーブル１１には、統合データベースにデータを供給する主幹ＡＰＩと統合データベースからデータを取得する利用ＡＰＩがある。主幹ＡＰＩは、ユーザからの入力等によりデータを受け取り、これを統合データベースに入力する。例えば、連携用ＡＰＩ管理テーブル１１に記載されているように、従業員取込ＡＰＩ（Ａｉ）は、従業員の情報を取り込み、識別名Ａで示されるアプリケーション（人事給与アプリケーション）が使用するための従業員の情報を統合データベースへ入力する（Ａｉのｉで示される）。他方、利用ＡＰＩは、利用したいデータを生成するアプリケーションのデータを、統合データベースから読み出すインターフェースとなっており、例えば、従業員参照ＡＰＩ（Ａｏ）は、識別名Ａで示される人事給与アプリケーションの作成したデータを、統合データベースから読み出す（Ａｏのｏで示される）ものである。
【００１３】
連携用ＡＰＩ管理テーブル１１においては、上記と同様に、Ｂｉは、識別名Ｂの会計アプリケーションのためのデータを統合データベースへ入力（ｉ）し、Ｃｉは、識別名Ｃの販売アプリケーションのためのデータを統合データベースへ入力（ｉ）し、Ｂｏは、識別名Ｂの会計アプリケーションのデータを統合データベースから読み出し（ｏ）、Ｃｏは、識別名Ｃの販売アプリケーションのデータを統合データベースから読み出し（ｏ）、ＡＢｏは、人事給与アプリケーションと会計アプリケーションのデータを統合データベースから読み出すインターフェースであることを示している。
【００１４】
３）に示されるように、ＡＰＩを利用するアプリケーション側では、それぞれ、異なるアプリケーション間で共通のインターフェースとして作られた、連携用ＡＰＩ管理テーブルによって管理されているＡＰＩをCall分で呼び出して使用する。このとき、ＡＰＩの呼び出し文において、引数のフォーマットは共通となっており、引き渡されるdata、データを利用するアプリケーションの識別名（Ｄ、Ｅ、Ｆ）、返り値ｒｅｓを引数とする。
【００１５】
本発明の実施形態で使用するＡＰＩは、実行される毎にログを出力するように作られる。４）に示されるように、ＡＰＩ  ＵＳＥ  history  table１２が設けられ、各ＡＰＩが実行されるたびに、実行日時秒、実行されたＡＰＩ名、呼び出したアプリケーション識別名、返り値である実行結果がログとして記録される。このＡＰＩ  ＵＳＥ  history  table１２を用いて、６）に示されるアプリケーション間連携図を生成する。この場合、アプリ間連携図を生成する特別なアプリケーションを用いて、自動的にアプリケーション間連携図を生成する。ＡＰＩ  ＵＳＥ  history  table１２が記録されているので、アプリケーション間の利用関係が簡単にわかり、連携状態の自動検出が可能になる。
【００１６】
図２は、本発明の実施形態の利用手順を説明する図である。
本発明の実施形態を利用する場合には、事前設定・準備の段階とＡＰＩを使用する段階がある。事前設定・準備段階では、ＡＰＩを作成する。具体的には、連携対象となるアプリケーションを登録する。そして、ＡＰＩを主幹ＡＰＩと利用ＡＰＩに分類し、作成するＡＰＩ名称を規定する。ＡＰＩは種類と、利用ＡＰＩがどの主幹ＡＰＩから発生したデータを扱うかが分かるように管理する。主幹ＡＰＩの名称には、アプリケーション識別名と主幹ＡＰＩの種類（ｉ）が分かる名称構成にする。利用ＡＰＩの名称は、主幹データ情報と、利用ＡＰＩの種類（ｏ）が分かるようにする。そして、ＡＰＩを使用する段階において、ＡＰＩを呼び出す元のアプリケーション識別名を設定して呼び出す。
【００１７】
図３は、本発明の実施形態の処理フローである。
図３（ａ）では、ＡＰＩの実行とＡＰＩ  ＵＳＥ  history  tableの作成処理を示している。ステップＳ１０において、アプリケーションを実行開始する。ステップＳ１１において、アプリケーション連携用のＡＰＩを呼び出し、実行する。ステップＳ１２において、ＡＰＩの処理結果がＮＧかＯＫかを判断する。ＮＧだった場合には、エラーログテーブルに情報を書き込んで処理を終了する。ＯＫだった場合には、ステップＳ１３において、アプリケーション種別情報を取得し、ステップＳ１４において、ＡＰＩ名称情報を解析し、ステップＳ１５において、ＡＰＩ  ＵＳＥ  historyを作成する。ＡＰＩ  ＵＳＥ  historyは、ＡＰＩの使われ方のログであり、これはＡＰＩ  ＵＳＥ  history  tableに格納される。
【００１８】
図３（ｂ）では、ＡＰＩ  ＵＳＥ  history  tableを用いて、アプリケーション間連携図を作成する。ステップＳ２１において、アプリ識別テーブルを参照し、ステップＳ２２で、ＡＰＩ  ＵＳＥ  history  tableを参照・解析する。ステップＳ２３において、関連アプリケーションの一覧図を作成し、ステップＳ２４において、アプリケーション間連携図を作成する。
【００１９】
図４及び図５は、アプリケーション間連携図を用いたアプリケーション間の連携状態の把握方法を説明する図である。
図４においては、各アプリケーションを示すアイコンを線で結んだアプリケーション間連携図が示されている。このような図によれば、あるアプリケーションを修正した時、どのアプリケーションに影響があるかを簡単に把握することができる。また、連携状態の情報の提供の仕方として、連携の線をマウスなどで選択指示すると、図４右に示すようなテキストでの情報を提示することが考えられる。このテキストで提示される情報は、ＡＰＩ  ＵＳＥ  history  tableから取得された情報である。
【００２０】
また、図５においては、連携による負荷状態を視覚的に示す図が示されている。図４の表示モードを切りかえる事により、図５の表示を可能とすればよい。各連携負荷状態をアクセス回数とデータ容量の総計で表示する。アクセス回数は、例えば、１〜１０の比率で表記することが考えられる。データ量は、線の太さや色で示すことが考えられる。また、詳細情報は各線を選択指示することで参照可能とする。
【００２１】
このような表示を利用すれば、アプリケーションの連携状態を漏れなく把握でき、アプリケーションを修正する場合の影響範囲を捉えることができる。また、全体の使われる頻度も把握することで、保守／メンテナンス、改善の必要性を事前に捉えることができる。
【００２２】
また、統合データベースにおいては、データの量が膨大になると考えられ、１つのデータベースで全てを管理していると不都合な場合が生じる。この場合、データベースを分離できると都合がよい。
【００２３】
図６は、データベースの分離処理のフローチャートである。
図６（ａ）においては、ステップＳ３０において、前述のアプリケーション間連携図において、連携の線をドラッグする。ステップＳ３１において、ドラッグ先が既存のデータベース上であるか否かを判断する。ステップＳ３１の判断がＮｏの場合には、ステップＳ３２において、作成するデータベース情報を入力し、ステップＳ３３において、データベース名の重複をチェックし、ステップＳ３４において、データベース名が重複している場合には、ステップＳ3２に戻り、重複していない場合には、ステップＳ３７に進む。ステップＳ３１の判断がＹｅｓの場合には、ステップＳ３５において、テーブル名重複チェックを行い、ステップＳ３６において、重複を判断し、重複していない場合には、ステップＳ3７に進み、重複している場合には、ステップＳ3０に戻る。
【００２４】
ステップＳ３７においては、新規エリア作成エリア内にドラックしたシステムと連携線を作成する。新規エリア作成エリアは、あるアプリケーションの連携からなるシステムを既存の統合データベースシステムから分離する場合に、アプリケーション間連携図上で分離するアプリケーション連携システムをドラッグして持っていく場所である。ステップＳ３８において、新たにデータを格納するテーブルを作成し、ステップＳ３９において、ドラッグされたアプリケーション間連携システムの接続先を新たに作成されたテーブルへと変更する。
【００２５】
図６（ｂ）は、図６（ａ）のテーブル名重複チェック処理の詳細を示す。ステップＳ４０において、ＡＰＩ管理情報を取得し、ステップＳ４１において、作成対象データベース上に同じテーブル名があるか否かをチェックする。
【００２６】
図６（ｃ）は、図６（ａ）のテーブル作成処理の詳細を示す。ステップＳ４２において、ＡＰＩ管理情報を取得し、ステップＳ４３において、作成対象データベース上にテーブルを作成する。
【００２７】
図７及び図８は、データベース分離の様子を説明する図である。
図７に示されるように、アプリケーションＡとＥの連携システムを既存データベース以外の場所にドラッグする（１）。ドラッグが解除されると、データベース情報入力画面が表示され、データベースサーバIP、やデータベース名を入力する。すると、既存のデータベース以外に、新規データベースが作成される。分離後は、アプリケーションＡとＥの連携処理において使用されるデータは、既存の統合データベースではなくて、新規のデータベースに格納されるようになる。
【００２８】
図８に示されるように、アプリケーションＡとＥの連携システムを他のデータベース上にドラッグすると、アプリケーションＡとＥの連携処理において使用されるデータは、新しい他のデータベース上に格納されるようになる。
【図面の簡単な説明】
【００２９】
【図１】本発明の実施形態の構成及び動作を説明する図である。
【図２】本発明の実施形態の利用手順を説明する図である。
【図３】本発明の実施形態の処理フローである。
【図４】アプリケーション間連携図を用いたアプリケーション間の連携状態の把握方法を説明する図（その１）である。
【図５】アプリケーション間連携図を用いたアプリケーション間の連携状態の把握方法を説明する図（その２）である。
【図６】データベースの分離処理のフローチャートである。
【図７】データベース分離の様子を説明する図（その１）である。
【図８】データベース分離の様子を説明する図（その２）である。
【符号の説明】
【００３０】
１０      アプリ識別テーブル
１１      連携用ＡＰＩ管理テーブル
１２      ＡＰＩ  ＵＳＥ  history  table
【図２】
2006277403.tif 000003
【図４】
2006277403.tif 000004
【図５】
2006277403.tif 000005
【図６】
2006277403.tif 000006
【図１】
2006277403.tif 000007
【図３】
2006277403.tif 000008
【図７】
2006277403.tif 000009
【図８】
2006277403.tif 000010