特許 7565705 ＡＰＩ提供システム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-10-03

(45)【発行日】2024-10-11

(54)【発明の名称】ＡＰＩ提供システム

(51)【国際特許分類】

   G06F 9/48 20060101AFI20241004BHJP

【ＦＩ】

G06F9/48 300B

【請求項の数】 5

(21)【出願番号】P 2020082372

(22)【出願日】2020-05-08

(65)【公開番号】P2021177310

(43)【公開日】2021-11-11

【審査請求日】2022-11-21

(73)【特許権者】

【識別番号】000006013

【氏名又は名称】三菱電機株式会社

(74)【代理人】

【識別番号】110002941

【氏名又は名称】弁理士法人ぱるも特許事務所

(72)【発明者】

【氏名】梅澤 和大

【審査官】坂東 博司

(56)【参考文献】

【文献】特開２０１７－０１６４０８（ＪＰ，Ａ）

【文献】特許第３７４５８２０（ＪＰ，Ｂ２）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｆ ９／４８

(57)【特許請求の範囲】

【請求項1】

ＡＰＩ要求を時系列に受け付けるＡＰＩメッセージ受付部と、前記ＡＰＩメッセージ受付部で受け付けた順番に前記ＡＰＩ要求を蓄積する処理蓄積部と、前記処理蓄積部が蓄積した前記ＡＰＩ要求を受け付けた順番から処理する順序として格納するＡＰＩ要求格納部と、前記ＡＰＩメッセージ受付部で受け付けた前記ＡＰＩ要求の処理の順位を変更する優先度変更部と、前記ＡＰＩ要求を受け付けると順次、前記ＡＰＩ要求格納部に記憶した処理の優先順位に従って前記ＡＰＩ要求を実行する処理実行部とを備え、
前記処理蓄積部は、前記ＡＰＩ要求を新たに前記ＡＰＩ要求格納部に格納する際、前記ＡＰＩ要求格納部に既に同じ要求元からの同じ前記ＡＰＩ要求が存在する場合は、前記ＡＰＩ要求を新たに格納する代わりに前記優先度変更部を呼び出して、
前記優先度変更部は、前記ＡＰＩ要求格納部に既に存在する前記ＡＰＩ要求の処理順序を一つ繰り上げることを特徴としたＡＰＩ提供システム。

【請求項2】

前記処理蓄積部は、前記ＡＰＩ要求を新たに前記ＡＰＩ要求格納部に格納する際、新たに格納する前記ＡＰＩ要求の処理順序の直後に、当該ＡＰＩ要求に対応した仮想の要求を生成して前記ＡＰＩ要求格納部に格納することにより、
前記優先度変更部は、前記ＡＰＩ要求の処理順序を一つ繰り上げる際、前記ＡＰＩ要求格納部に既に対応する前記仮想の要求が存在する場合、前記仮想の要求を超えて前記ＡＰＩ要求の処理順序を繰り上げないことを特徴とした請求項１に記載のＡＰＩ提供システム。

【請求項3】

前記処理蓄積部は、前記ＡＰＩ要求を新たに前記ＡＰＩ要求格納部に格納する際、新たに格納する前記ＡＰＩ要求の処理順序の直後に、当該ＡＰＩ要求に対応した仮想の要求を生成して前記ＡＰＩ要求格納部に格納する一方、当該ＡＰＩ要求に対応した仮想の要求が前記ＡＰＩ要求格納部に既に存在する場合、新たに前記仮想の要求を生成しないことを特徴とした請求項２に記載のＡＰＩ提供システム。

【請求項4】

前記優先度変更部は、前記ＡＰＩ要求の処理順序を一つ繰り上げる際、前記ＡＰＩ要求格納部に既に存在する前記ＡＰＩ要求の処理順序が最も早い場合、前記ＡＰＩ要求の処理順序を変更しないことを特徴とした請求項１から請求項３のいずれか１項に記載のＡＰＩ提供システム。

【請求項5】

前記優先度変更部は、前記ＡＰＩ要求格納部に新たに格納される前記ＡＰＩ要求が前記ＡＰＩ要求格納部に既に格納され一つ早い処理順序の前記ＡＰＩ要求と同じ要求元からの同じ前記ＡＰＩ要求である場合、既に格納されている前記ＡＰＩ要求の処理順序を変更しないことを特徴とした請求項１から請求項４のいずれか１項に記載のＡＰＩ提供システム。

【発明の詳細な説明】

【技術分野】

【0001】

本願は、ＡＰＩ提供システムに関するものである。

【背景技術】

【0002】

従来のＡＰＩ提供システムは、ＡＰＩ（Application Programming Interface）要求に対して要求順に処理を行うが、ＡＰＩ要求の優先度が考慮されない場合、過多なＡＰＩ要求の後に優先度の高い要求があった場合でも過多な要求をすべて処理するまで高優先度の要求を処理することができず問題がある。
このため、要求者または要求元システムを示す固有の識別子と優先度との組合せを予め登録しておき、この登録情報に基づいてＡＰＩ要求を優先処理するものが知られている（特許文献１参照）。

【先行技術文献】

【特許文献】

【0003】

【文献】特開２０１７－１６４０８号公報

【発明の概要】

【発明が解決しようとする課題】

【0004】

しかしながら、上記特許文献１に開示されているＡＰＩ提供システムにおいては、予め要求者または要求元システムを示す固有の識別子と優先度との組合せを登録する必要があり、一般的なユーザに対して汎用性に欠けるものであった。
本願は、上述のような課題を解決するための技術を開示するものであり、要求者または要求元システムを示す固有の識別子と優先度との組合せを登録する必要がなく、優先度の高い要求を優先処理することが可能なＡＰＩ提供システムを提供することを目的とする。

【課題を解決するための手段】

【0005】

本願に係るＡＰＩ提供システムは、ＡＰＩ要求を時系列に受け付けるＡＰＩメッセージ受付部と、前記ＡＰＩメッセージ受付部で受け付けた順番に前記ＡＰＩ要求を蓄積する処理蓄積部と、前記処理蓄積部が蓄積した前記ＡＰＩ要求を受け付けた順番から処理する順序として格納するＡＰＩ要求格納部と、前記ＡＰＩメッセージ受付部で受け付けた前記ＡＰＩ要求の処理の順位を変更する優先度変更部と、前記ＡＰＩ要求を受け付けると順次、前記ＡＰＩ要求格納部に記憶した処理の優先順位に従って前記ＡＰＩ要求を実行する処理実行部とを備え、前記処理蓄積部は、前記ＡＰＩ要求を新たに前記ＡＰＩ要求格納部に格納する際、前記ＡＰＩ要求格納部に既に同じ要求元からの同じ前記ＡＰＩ要求が存在する場合は、前記ＡＰＩ要求を新たに格納する代わりに前記優先度変更部を呼び出して、前記優先度変更部は、前記ＡＰＩ要求格納部に既に存在する前記ＡＰＩ要求の処理順序を一つ繰り上げることを特徴としたものである。

【発明の効果】

【0006】

本願に係るＡＰＩ提供システムによれば、ＡＰＩ要求頻度が多い場合に優先的に処理を実行させることができる汎用性の高いシステムとすることができる。

【図面の簡単な説明】

【0007】

【図1】実施の形態１に係るＡＰＩ提供システムの全体構成を示すブロック図である。

【図2】実施の形態１に係るＡＰＩ提供システムのハードウエア構成を示すブロック図である。

【図3】実施の形態１に係るＡＰＩ提供システムの動作を説明するためのフローチャートである。

【図4】実施の形態１に係るＡＰＩ提供システムの処理データの時系列遷移を説明する概念図である。

【図5】実施の形態１に係るＡＰＩ提供システムの処理データの時系列遷移を説明する概念図である。

【図6】実施の形態１に係るＡＰＩ提供システムの処理データの時系列遷移を説明する概念図である。

【発明を実施するための形態】

【0008】

実施の形態１．
図１は、実施の形態１に係るＡＰＩ提供システムの全体構成を示すブロック図である。
図において、ＡＰＩ提供システム１は、一般的なユーザ（要求元）であるＡＰＩ要求部Ａ、ＡＰＩ要求部Ｂ、ＡＰＩ要求部Ｃ、ＡＰＩ要求部Ｄ、ＡＰＩ要求部Ｅなどから要求されるＡＰＩ要求に基づいて順次アプリケーションを提供するように構成されたもので、ＡＰＩ要求を受付けるＡＰＩメッセージ受付部１０と、ＡＰＩメッセージ受付部１０で受付けたＡＰＩ要求を蓄積する処理蓄積部１１と、処理蓄積部１１が蓄積した新規ＡＰＩ要求を格納するＡＰＩ要求格納部１２と、ＡＰＩ要求の処理の優先順位を変更する優先度変更部１３と、ＡＰＩ要求格納部１２に記憶した処理の優先順位に従ってＡＰＩ要求を実行する処理実行部１４とから構成されている。

【0009】

ここで、ＡＰＩ提供システム１における各構成部分は、例えば、図２に示すようにマイクロプロセッサ２０とプログラムおよび各種情報を記憶するメモリ２１とによって形成されるものである。

【0010】

次に、上述のように構成されたＡＰＩ提供システムの動作について、図３に示すフローチャートに基づいて説明する。
まず、ステップＳ１０１において、ＡＰＩメッセージ受付部１０に新規に受け付けたＡＰＩ要求があるか判断し、ＡＰＩ要求がある場合、処理蓄積部１１は、このＡＰＩ要求を蓄積する（ステップＳ１０２）。

【0011】

次に、ステップＳ１０３において、ステップＳ１０２で蓄積したＡＰＩ要求がＡＰＩ要求格納部１２に格納されているか否かを判断する。ここで、ＡＰＩ要求が格納されていない場合（Ｎ）、ステップＳ１０４へ移行してＡＰＩ要求格納部１２に仮想のＡＰＩ要求が格納されているかを判断し、格納されていない場合（Ｎ）、ＡＰＩ要求格納部１２は、実際のＡＰＩ要求を格納し、実際のＡＰＩ要求に対応する仮想のＡＰＩ要求を生成して追加格納する（ステップＳ１０５）。
また、ステップＳ１０４で仮想のＡＰＩ要求が格納されている場合（Ｙ）、ステップＳ１０６に移行して実際のＡＰＩ要求のみを格納する。

【0012】

一方、ステップＳ１０３において、実際のＡＰＩ要求が既に格納されている場合（Ｙ）、ステップＳ１０７へ移行し、ＡＰＩ要求格納部１２に仮想のＡＰＩ要求が直前に格納されているか否かを判断する。ここで、仮想のＡＰＩ要求が直前に格納されていない場合（Ｎ）、優先度変更部１３によりＡＰＩ要求格納部１２は、実際のＡＰＩ要求の処理順位を一つ繰上げる処理のみを行い、新たなＡＰＩ要求を格納しない。また、仮想のＡＰＩ要求が直前に格納されている場合（Ｙ）、優先度変更部１３による繰上げ処理を行わない。
以上のような処理ステップを経てステップＳ１０１に戻り、次の新規受け付けメッセージがあるか判断し、新規受け付けメッセージがなくなるまで同様の処理を繰り返すことになる。
なお、処理実行部１４は、上述のステップを経てＡＰＩ要求格納部１２に格納されたＡＰＩ要求の処理順位に従って処理を実行して行くことになる。

【0013】

次に、ＡＰＩ提供システムにおける具体的な処理データの時系列遷移について図４～図６を用いて説明する。
各図において、上欄は、ＡＰＩメッセージ受付部１０において受け付けた新規ＡＰＩ要求を表す新規リクエストの表を示し、下欄は、ＡＰＩ要求格納部１２において格納されたＡＰＩ要求の処理の順序を示している。また、左側から右側へ時間の推移を示し、要求順序は、新規ＡＰＩ要求を受け付けた順番を、要求内容は、処理実行部１４にて実行する処理の種類を、要求元は、ＡＰＩ要求部Ａ～Ｅのいずれかからの要求であるかを示している。さらに、ここでは要求内容として処理１および処理１’のみが要求されているものとして説明し、処理１は、実際に要求された実処理要求であり、処理１’は、実処理要求に伴って形成される仮想処理要求を示している。

【0014】

図４において、初期の時刻ｔ１にはＡＰＩ要求格納部１２に処理要求が蓄積されていない状態にあり、ＡＰＩメッセージ受付部１０が６件の新規リクエストを受け付けたものとする。
まず、時刻ｔ１に受付けた新規リクエストの表の要求順序１である要求元Ａからの処理１を処理蓄積部１１は、時刻ｔ２時においてＡＰＩ要求格納部１２に格納するとともに仮想要求である要求元Ａからの処理１’を生成して処理１の直後に追加する。このとき、ＡＰＩメッセージ受付部１０には新規リクエストが入力されていないものとし、５件の新規リクエストが残存していることになる。

【0015】

次に、時刻ｔ３において、処理蓄積部１１は、新規リクエストの表に残存している要求順序１である要求元Ｂからの処理１をＡＰＩ要求格納部１２に格納し、仮想要求である要求元Ｂからの処理１’を生成して直後に追加する。このとき、ＡＰＩメッセージ受付部１０には、新規リクエストが入力されていないものとし、４件の新規リクエストが残存していることになる。

【0016】

次に、時刻ｔ４において、処理蓄積部１１は、新規リクエストの表に残存している要求順序１である要求元Ｃからの処理１をＡＰＩ要求格納部１２に格納し、仮想要求である要求元Ｃからの処理１’を生成して直後に追加する。このとき、ＡＰＩメッセージ受付部１０には、新規リクエストが入力されていないものとし、３件の新規リクエストが残存していることになる。

【0017】

次に、時刻ｔ５において、処理蓄積部１１は、新規リクエストの表に残存している要求順序１である要求元Ｄからの処理１をＡＰＩ要求格納部１２に格納し、仮想要求である要求元Ｄからの処理１’を生成して直後に追加する。このとき、ＡＰＩメッセージ受付部１０には、新規リクエストが入力されていないものとし、２件の新規リクエストが残存していることになる。

【0018】

次に、時刻ｔ６において、処理蓄積部１１は、新規リクエストの表に残存している要求順序１である要求元Ｄからの処理１をＡＰＩ要求格納部１２に格納しようとするが、ＡＰＩ要求格納部１２には既に要求元Ｄからの処理１が存在するため、要求元Ｄからの処理１をＡＰＩ要求格納部１２に格納する代わりに優先度変更部１３を呼び出し、優先度変更部１３は、要求元Ｄからの処理１の処理順序を一つ繰り上げる処理を行うことになる。このとき、ＡＰＩメッセージ受付部１０には、新規リクエストが入力されていないものとし、１件の新規リクエストが残存していることになる。

【0019】

次に、時刻ｔ７において、処理蓄積部１１は、新規リクエストの表に残存している要求順序１である要求元Ｄからの処理１をＡＰＩ要求格納部１２に格納しようとするが、ＡＰＩ要求格納部１２には既に要求元Ｄからの処理１が存在するため、要求元Ｄからの処理１をＡＰＩ要求格納部１２に格納する代わりに優先度変更部１３を呼び出し、優先度変更部１３は、要求元Ｄからの処理１の処理順序を一つ繰り上げる処理を行うことになる。このとき、ＡＰＩメッセージ受付部１０には、新規リクエストが入力されていないものとし、残存した新規リクエストが０件になる。

【0020】

次に、図５に示すように、時刻ｔ８において、新たに６件のリクエストをＡＰＩメッセージ受付部１０が受付けたとする。
時刻ｔ８に受付けた新規リクエストの表の要求順序１である要求元Ｄからの処理１を処理蓄積部１１は、時刻ｔ９において、ＡＰＩ要求格納部１２に格納しようとするが、ＡＰＩ要求格納部１２には既に要求元Ｄからの処理１が存在するため、要求元Ｄからの処理１をＡＰＩ要求格納部１２に格納する代わりに優先度変更部１３を呼び出し、優先度変更部１３は、要求元Ｄからの処理１の処理順序を一つ繰り上げる処理を行うことになる。このとき、ＡＰＩメッセージ受付部１０には、新規リクエストが入力されていないものとし、５件の新規リクエストが残存していることになる。

【0021】

次に、時刻ｔ１０において、処理蓄積部１１は、新規リクエストの表に残存している要求順序１である要求元Ｄからの処理１をＡＰＩ要求格納部１２に格納しようとするが、ＡＰＩ要求格納部１２には既に要求元Ｄからの処理１が存在するため、上記と同様に、優先度変更部１３は、要求元Ｄからの処理１の処理順序を一つ繰り上げる処理を行うことになる。このとき、ＡＰＩメッセージ受付部１０には、新規リクエストが入力されていないものとし、４件の新規リクエストが残存していることになる。

【0022】

次に、時刻ｔ１１において、処理蓄積部１１は、新規リクエストの表に残存している要求順序１である要求元Ｄからの処理１をＡＰＩ要求格納部１２に格納しようとするが、ＡＰＩ要求格納部１２には既に要求元Ｄからの処理１が存在するため、上記と同様に、優先度変更部１３は、要求元Ｄからの処理１の処理順序を一つ繰り上げる処理を行うことになる。このとき、ＡＰＩメッセージ受付部１０には、新規リクエストが入力されていないものとし、３件の新規リクエストが残存していることになる。

【0023】

次に、時刻ｔ１２において、処理蓄積部１１は、新規リクエストの表に残存している要求順序１である要求元Ｄからの処理１をＡＰＩ要求格納部１２に格納しようとするが、ＡＰＩ要求格納部１２には既に要求元Ｄからの処理１が存在するため、上記と同様に、優先度変更部１３は、要求元Ｄからの処理１の処理順序を一つ繰り上げる処理を行うことになる。このとき、ＡＰＩメッセージ受付部１０には、新規リクエストが入力されていないものとし、２件の新規リクエストが残存していることになる。

【0024】

次に、時刻ｔ１３において、処理蓄積部１１は、新規リクエストの表に残存している要求順序１である要求元Ｄからの処理１をＡＰＩ要求格納部１２に格納しようとするが、ＡＰＩ要求格納部１２には既に要求元Ｄからの処理１が存在するため、要求元Ｄからの処理１をＡＰＩ要求格納部１２に格納する代わりに優先度変更部１３を呼び出す。ここで、優先度変更部１３は、要求元Ｄからの処理１の処理順序を一つ繰り上げようとするが、要求元Ｄからの処理１の処理順序は、既に「１」であるため、処理順序を変更しないことにする。このとき、ＡＰＩメッセージ受付部１０には、新規リクエストが入力されていないものとし、１件の新規リクエストが残存していることになる。

【0025】

次に、時刻ｔ１４において、新規リクエストの表に残存している要求順序１である要求元Ｅからの処理１を処理蓄積部１１は、ＡＰＩ要求格納部１２に格納し、仮想要求である要求元Ｅからの処理１’を生成して処理１の直後に追加する。このとき、残存している新規リクエストが０件となる。また、ここで処理実行部１４が要求順序１の要求元Ｄからの処理１を実行したとすると、ＡＰＩ要求格納部１２の処理順序は、１繰り上がり、図６における時刻ｔ１５に示すものとなる。

【0026】

次に、図６に示すように、時刻ｔ１５において、ＡＰＩメッセージ受付部１０が新たに４件のリクエストを受付けたとする。
時刻ｔ１５に受付けた新規リクエストの表の要求順序１である要求元Ｄからの処理１を処理蓄積部１１は、時刻ｔ１６において、新規リクエストの表の要求順序１である要求元Ｄからの処理１をＡＰＩ要求格納部１２に格納し、仮想要求である要求元Ｄからの処理１’を生成しようとするが、ＡＰＩ要求格納部１２には既に要求元Ｄからの処理１の仮想要求である処理１’が存在するため、要求元Ｄからの処理１’を新たに生成しない。このとき、ＡＰＩメッセージ受付部１０には、新規リクエストが入力されていないものとし、３件の新規リクエストが残存していることになる。

【0027】

次に、時刻ｔ１７において、処理蓄積部１１は、新規リクエストの表の要求順序１である要求元Ｄからの処理１をＡＰＩ要求格納部１２に格納しようとするが、ＡＰＩ要求格納部１２には既に要求元Ｄからの処理１が存在するため、要求元Ｄからの処理１をＡＰＩ要求格納部１２に格納する代わりに優先度変更部１３を呼び出し、優先度変更部１３は、要求元Ｄからの処理１の処理順序を一つ繰り上げる。このとき、ＡＰＩメッセージ受付部１０には、新規リクエストが入力されていないものとし、２件の新規リクエストが残存していることになる。

【0028】

次に、時刻ｔ１８において、処理蓄積部１１は、新規リクエストの表の要求順序１である要求元Ｄからの処理１をＡＰＩ要求格納部１２に格納しようとするが、ＡＰＩ要求格納部１２には既に要求元Ｄからの処理１が存在するため、要求元Ｄからの処理１をＡＰＩ要求格納部１２に格納する代わりに優先度変更部１３を呼び出し、優先度変更部１３は、要求元Ｄからの処理１の処理順序を一つ繰り上げる。このとき、ＡＰＩメッセージ受付部１０には、新規リクエストが入力されていないものとし、１件の新規リクエストが残存していることになる。

【0029】

次に、時刻ｔ１９において、処理蓄積部１１は、新規リクエストの表の要求順序１である要求元Ｄからの処理１をＡＰＩ要求格納部１２に格納しようとするが、ＡＰＩ要求格納部１２には既に要求元Ｄからの処理１が存在するため、要求元Ｄからの処理１をＡＰＩ要求格納部１２に格納する代わりに優先度変更部１３を呼び出し、優先度変更部１３は、要求元Ｄからの処理１の処理順序を一つ繰り上げようとする。しかし、要求元Ｄからの処理１よりも処理順序が１つ早い要求が要求元Ｄからの処理１の仮想要求である処理１’であるため、処理順序を変更しない。
なお、上述の実施の形態においては、ＡＰＩメッセージ受付部１０の新規のＡＰＩ要求を６件として説明したが、これに限られるものでもなく、また、ＡＰＩ要求格納部１２の格納件数も必要に応じて設定することが可能である。

【0030】

以上のように、本願に係るＡＰＩ提供システムは、ＡＰＩ要求を受けた際、この実際の要求に対応する仮想の要求を生成して実要求の処理順序の直後に格納し、同じ要求元から全く同じ要求があった場合、要求数に応じて要求の処理順序を繰り上げ、かつ、仮想の要求の処理順序は繰り上げず、実際の要求の処理後、仮想の要求が処理待機中の要求に残存している場合は、仮想の要求を新たに生成せず、加えて、実際の要求は、自身の仮想の要求を超えて処理順序を繰り上げることはできないように構成することによって、ＡＰＩ要求頻度が多い場合に優先的に処理を実行させることができるとともに、複数回の実処理要求については、優先処理を阻止することができ、過負荷を防止した優先処理を可能とすることができる。

【0031】

なお、上述の実施の形態に記載された様々な特徴、態様、及び機能は、特定の実施の形態の適用に限られるのではなく、本願は、単独で、または様々な組み合わせで実施の形態に適用可能である。

【符号の説明】

【0032】

１：ＡＰＩ提供システム、 Ａ～Ｅ：ＡＰＩ要求部、
１０：ＡＰＩメッセージ受付部、 １１：処理蓄積部、 １２：ＡＰＩ要求格納部、
１３：優先度変更部、 １４：処理実行部

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】