JP2023501850A - ビジネス監査報知方法及びゲートウェイ、電子機器、読取可能な媒体及びコンピュータプログラム - Google Patents

Abstract

本願は、ビジネス監査報知方法を提供し、コンピュータ分野に関し、具体的にクラウドコンピューティング及びクラウドプラットフォーム技術分野に関する。具体的な実現技術案は、ユーザ端末の操作要求に応答して、監査プラットフォームにビジネス監査要求を送信し、前記監査プラットフォームにより返送された監査任務識別子に基づいて、報知待ちメッセージを生成し、取得された監査結果及び前記報知待ちメッセージに基づいて、監査報知メッセージを生成し、前記監査報知メッセージを前記ユーザ端末にプッシュする。この方法は、汎用性があり、開発人員の人力コストを低減し、コード冗長性を低下させ、かつビジネスコードのメンテナンス性を向上することができる。本願は、ゲートウェイ、電子機器、読取可能な媒体及びコンピュータプログラムをさらに提供した。

Description

本発明は、本願はコンピュータ技術分野に関し、具体的にクラウドコンピューティング及びクラウドプラットフォーム技術に関し、特にビジネス監査報知方法及びゲートウェイ、電子機器、読取可能な媒体に関する。

ミニアプリは、ダウンロードや、インストールを必要とせずに使用可能なアプリケーションとして、ユーザの時間コスト及び携帯電話の内部メモリ容量を節約するとともに、開発者の開発コスト及び普及コストを大幅に低減することができる。

ミニアプリ開発者及び第三者の事業者は、例えばミニアプリパッケージ管理、基本情報設置、情報流れ・材料検索サービス、注文・支払いサービス、メッセージサービスなどのミニアプリの能力を豊富にするために、様々なアクセス使用方式を提供しており、プラットフォームインターフェースを介して操作することをサポートしてもよく、プラットフォームが提供したオープンアプリケーションプログラミングインターフェース（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ，ＡＰＩ）を呼び出すことで能力を使用してもよい。

第１の局面によれば、
ユーザ端末の操作要求に応答して監査プラットフォームにビジネス監査要求を送信することと、
前記監査プラットフォームにより返送された監査任務識別子に基づいて報知待ちメッセージを生成することと、
取得された監査結果及び前記報知待ちメッセージに基づいて、監査報知メッセージを生成することと、
前記監査報知メッセージを前記ユーザ端末にプッシュすることと、を含む、
ビジネス監査報知方法を提供した。

第２の局面によれば、
ゲートウェイがユーザ端末の操作要求に応答して送信したメッセージであるビジネス監査要求を受信することと、
監査結果を取得して記憶することで、前記ゲートウェイが、前記監査結果と、ゲートウェイが前記ビジネス監査要求に対して生成したメッセージである報知待ちメッセージとに基づいて、監査報知メッセージを生成することに供することと、を含む、
ビジネス監査報知方法を提供した。

第３の局面によれば、
ユーザ端末の操作要求に応答して、監査プラットフォームにビジネス監査要求を送信し、前記監査プラットフォームにより返送された監査任務識別子に基づいて、報知待ちメッセージを生成するように配置されている提出モジュールと、
取得された監査結果及び前記報知待ちメッセージに基づいて監査報知メッセージを生成し、前記監査報知メッセージを前記ユーザ端末にプッシュするように配置されているプッシュモジュールと、を含む、
ゲートウェイを提供した。

第４の局面によれば、
少なくとも１つのプロセッサと、
前記少なくとも１つのプロセッサと通信接続するメモリとを含む電子機器であって、
前記メモリに、前記少なくとも１つのプロセッサによって実行され得るコマンドが記憶されており、前記コマンドが前記少なくとも１つのプロセッサによって実行されることで、前記少なくとも１つのプロセッサがビジネス監査報知方法のいずれか一項に記載の方法を実行することができる、
電子機器を提供した。

第５の局面によれば、コンピュータに上述したいずれかのビジネス監査報知方法を実行させるためのコンピュータコマンドを記憶している非一時的なコンピュータ読取可能な記憶媒体を提供した。

第６の局面によれば、プロセッサによって実行されることで、上記分散記憶方法のいずれか一項に記載のビジネス監査報知方法を実現するコンピュータプログラムを含むコンピュータプログラム製品を提供した。

本願が提供したビジネス監査報知方法は、ユーザ端末により発された操作要求に応答して監査プラットフォームにビジネス監査要求を送信し、監査プラットフォームにより返送された監査任務識別子に基づいて、報知待ちメッセージを生成し、監査結果及び報知待ちメッセージに基づいて、監査報知メッセージを生成し、監査報知メッセージをユーザ端末にプッシュする。この方法は、汎用性があり、任意のタイプのビジネス監査（例えば、ミニアプリ能力の監査）をサポートするとともに、開発人員の人力コストを低減し、コード冗長性を低下させ、かつビジネスコードのメンテナンス性を向上することができる。

この部分で説明した内容は、本開示の実施例の肝心な又は重要な特徴を表記するためのものでもなく、本開示の範囲を限定するためのものでもないと理解すべきである。本開示の他の特徴は、以下の明細書によって理解し易くなるであろう。

図面は、本技術案がよりよく理解されるためのものであり、本願に対する限定を構成しない。
本願の実施例が提供したビジネス監査報知方法の適用場面模式図である。 本願の実施例が提供したビジネス監査報知方法のフローチャートである。 本願の実施例が提供したユーザの操作要求に応答して監査プラットフォームにビジネス監査要求を送信するフローチャートである。 本願の実施例が提供した監査報知メッセージをユーザ端末にプッシュするフローチャートである。 本願の実施例が提供したビジネス監査報知方法のフローチャートである。 本願の実施例が提供したゲートウェイの原理ブロック図である。 本願の実施例が提供した提出モジュールの原理ブロック図である。 本願の実施例が提供した認証手段の原理ブロック図である。 本願の実施例が提供したプッシュモジュールの原理ブロック図である。 本願の実施例が提供した別のプッシュモジュールの原理ブロック図である。 本願の実施例が提供した監査プラットフォームの原理ブロック図である。 本実施例が提供したビジネス監査報知方法のフローチャートである。 本願の実施例のビジネス監査報知方法を実現するための電子機器のブロック図である。

以下、図面に合わせて本願の例示的な実施例について説明する。その中、理解に役立つように本願の実施例の各詳細を含み、これらはあくまで例示的なものであると理解すべきである。そのため、当業者は、本願の範囲及び趣旨から逸脱せずに、ただし説明した実施例に対して、様々な変更や、修正をなし得ることを認識すべきである。同様に、明確及び簡明のために、以下の説明において公知の機能及び構成に対する説明を省略している。

衝突しない場合、本願の各実施例及び実施例における各特徴は互いに組み合わせることができる。

本明細書で使用されるような「及び/又は」という用語は、一つ又は複数の関連列挙アイテムの任意及び全ての組み合わせを含む。

本明細書で使用される用語は、特定の実施例を説明するためのものに過ぎず、本願を限定することを意図しない。文脈から別途明らかに指摘しない限り、本明細書で使用されるような「一つ」及び「この」という単数形は、複数形も含むことを意図する。さらに理解すべきことは、本明細書において「含む」及び/又は「・・・で製作される」という用語を使用する場合、前記特徴、全体、ステップ、操作、素子及び/又はアセンブリが存在することを指定するが、一つ又は複数の他の特徴、全体、ステップ、操作、素子、アセンブリ及び/又はそのグループが存在すること、又は追加することを除外しない。

本願の実施例が指すミニアプリとは、ダウンロードや、インストールを必要とせずにリアルタイム通信アプリケーション上で実行され得るアプリケーションプログラムであり、一般的に第三者のアプリケーションにロードされる。ミニアプリに対する修正又は操作行為は、監査プラットフォームの人工監査を経る必要があることが多いため、ミニアプリ開発者又は第三者の事業者は、オープンＡＰＩゲートウェイを呼び出す時に監査結果を即時に取得することができず、非同期報知メカニズムにより監査結果を報知する必要がある。

しかしながら、現在のオープンＡＰＩゲートウェイは、非同期報知メカニズムをサポートできないため、ミニアプリ能力の開発過程において、監査に係る操作場面ごとに、非同期報知機能をカスタマイズして開発する必要があり、これは開発人力をかかるだけでなく、コード冗長をもたらし、全体のサービス端のアーキテクチャのメンテナンス性を影響した。そして、異なる開発者が開発した非同期報知コードは、報知メッセージが必ず到着することを保証する統一のメカニズムがないため、報知メッセージのプッシュ漏れの状況が存在する可能性があり、ミニアプリ開発者又は第三者の事業者によるミニアプリ能力の使用を影響した。

オープンＡＰＩゲートウェイに存在する上記問題に対して、本願はビジネス監査報知方法を提供して、ＡＰＩゲートウェイの呼び出し及び非同期報知の機能閉ループを実現し、開発者の人力コストを低減し、コード冗長性を低下させ、ビジネスコードのメンテナンス性を向上させるために用いられる。

例示的に、図１は本願の実施例が提供したビジネス監査報知方法の適用場面模式図である。図１に示すように、この適用場面は、少なくとも一つのユーザ端末１１、ゲートウェイ１２及び監査プラットフォーム１３を含んでもよく、ユーザ端末１１、ゲートウェイ１２及び監査プラットフォーム１３は、ネットワークを介して通信する。ただし、ユーザ端末１１は、ミニアプリ開発者又は第三者の事業者が使用する端末であってもよい。ミニアプリ開発者及び第三者の事業者は、ユーザ端末１１で一つ又は複数のミニアプリを開発してもよく、既に存在しているミニアプリを修正してもよい。

一部の実施例において、ミニアプリ開発者及び第三者の事業者は、ミニアプリ開発プラットフォームを介してミニアプリ能力を修正することができる。ミニアプリ開発プラットフォームは、ミニアプリを搭載するアプリケーションプログラム（Ａｐｐｌｉｃａｔｉｏｎ，ＡＰＰ）運営者が独立して運営するプラットフォームであってもよく、ミニアプリを搭載するＡＰＰの運営者と連携関係を有する第三者のミニアプリ開発プラットフォームであってもよい。選択的に、このミニアプリ開発プラットフォームは、ミニアプリ開発者ツールとも呼ばれ、ミニアプリを生産し、修正するためのツールである。ミニアプリ開発プラットフォームの具体的な体現形式について、本願はそれを限定しない。

ゲートウェイ１２は、例えば、ミニアプリパッケージのリリース、ミニアプリ名称の修正などの、ユーザ端末１１により提出されたミニアプリ能力に対する操作要求を受信し、操作要求に基づいて監査プラットフォームにビジネス監査要求を送信して、ミニアプリの操作要求が関連規定に合致するか否かを監査し、同時に報知待ちメッセージを生成することで、監査結果を取得した後に監査報知メッセージを生成する。

監査プラットフォーム１３は、ビジネス監査要求の具体的な内容に応じて、ミニアプリ能力が正当であるか否かを監査し、監査結果をメッセージキューに記憶する。実際の応用において、この監査プラットフォーム１３は、クラウドサーバであってもよい。本願の実施例は、監査プラットフォームの具体的な形式を限定せず、それは実際のニーズに応じて確定することができ、ただしは説明を繰り返さない。

ゲートウェイ１１は、メッセージキューから監査結果を取得し、監査結果と報知待ちメッセージとを組み合わせて監査報知メッセージを取得し、さらに、監査報知メッセージをユーザ端末に送信し、ユーザはユーザ端末から監査結果を知ることができる。

以降、具体的な実施例によって本願の技術案を詳細に説明する。説明しておくことは、以下の幾つかの具体的な実施例は、互いに組み合わせてもよく、同じ又は類似な概念又は過程について、幾つかの実施例において説明を繰り返さない可能性がある。

第１の態様において、本願の実施例は、ゲートウェイに用いられるビジネス監査報知方法を提供し、このゲートウェイは、ＡＰＩゲートウェイであってもよく、信号を伝送するために用いられる他のゲートウェイであってもよい。

図２は、本願の実施例が提供したビジネス監査報知方法のフローチャートである。図２を参照して、本願の実施例が提供したビジネス監査報知方法は、
ユーザ端末により発された操作要求に応答して、監査プラットフォームにビジネス監査要求を送信するステップ２０１を含む。

ただし、ユーザは、使用しているユーザ端末により操作要求を発する。操作要求は、ミニアプリビジネスに対する要求であってもよく、他のアプリケーションプログラムに対する要求であってもよい。

一部の実施例において、操作要求は、ミニアプリの基本情報（例えば、名称、アバター、プロファイル、業界カテゴリなど）の修正、ミニアプリパッケージのリリース、配信材料の提出（検索・推奨ｆｅｅｄ）及び支払いサービスの開通などを含むが、これらに限られない。

説明の便利上、本願の実施例は、ユーザがユーザ端末により操作要求を発すことを、ユーザ端末が操作要求を発すこととして表現する。ただし、ユーザ端末は、携帯電話、携帯情報端末、パーソナルコンピュータ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ，ＰＣ）、複合機などの、通信機能を有する端末であってよい。

一部の実施例において、ユーザは、ミニアプリ開発者であってもよく、第３者の事業者であってもよい。ただし、ミニアプリ開発者は、ミニアプリの所有者又は管理者である。第３者の事業者は、ミニアプリ開発者が承認した第３者の事業者、又は管理者が承認した第３者の事業者である。ミニアプリ開発者又は管理者は、第３者の事業者に対してすべての使用権限を承認してもよく、一部の使用権限のみを承認してもよい。第３者の事業者は、ミニアプリ開発者又は管理者の承認権限内でミニアプリ能力を管理する。

一部の実施例において、ミニアプリ開発者又は管理者は、ミニアプリ能力を開発し、修正する開発過程において、監査プラットフォームがミニアプリ能力の正当性を監査するように、監査プラットフォームに監査を要求する必要がある。

一部の実施例において、ミニアプリプラットフォームは、例えば、ミニアプリパッケージ管理、基本情報設置、情報流れ・材料検索サービス、注文・支払いサービス、メッセージサービスなどのミニアプリ能力を豊富にするために、様々なアクセス使用方式を提供しており、ミニアプリプラットフォームインターフェースを介して操作してもよく、ミニアプリプラットフォームが提供したオープンＡＰＩを呼び出すことで能力を使用してもよい。

一部の実施例において、ユーザはゲートウェイに操作要求を発し、ただし、操作要求はミニアプリの基本情報（例えば、名称、アバター、プロファイル、業界カテゴリなど）の修正、ミニアプリパッケージのリリース、配信材料の提出（検索・推奨ｆｅｅｄ）及び支払いサービスの開通などを含むが、これらに限られない。操作要求には、ユーザ身元識別子及びアプリケーションプログラム識別子が付けられている。本実施例において、アプリケーションプログラム識別子は、任意の形式のミニアプリ識別子であってよい。

ただし、ユーザ身元識別子はユーザ身元を識別するための識別子であり、ミニアプリ識別子はミニアプリ身元を識別するための識別子である。操作タイプは、ミニアプリパッケージ、基本情報設置、情報流れ・材料検索サービス、注文・支払いサービス及びメッセージサービスを含むが、これらに限られない。操作パラメータは、操作タイプに関連しており、それぞれの操作タイプが異なるパラメータに対応する。例えば、ミニアプリパッケージをリリースする場合、ミニアプリパッケージ識別子（ｐａｃｋａｇｅ_ｉｄ）及びミニアプリパッケージバージョン（ｐａｃｋａｇｅ_ｖｅｒｓｉｏｎ）パラメータを提供する必要があり、ミニアプリ名称を修正する場合、ミニアプリ名称（ａｐｐ_ｎａｍｅ）パラメータを提供する必要がある。

一部の実施例において、ゲートウェイは、ユーザ端末により発された操作要求を受信した後に、監査プラットフォームにビジネス監査要求を送信する。監査プラットフォームは、人工、又は、機器と人工とを組合せる監査方式によって、ミニアプリを監査することができる。

ただし、監査要求と操作要求とは対応している。一部の実施例において、監査要求のタイプは、ミニアプリパッケージ監査、名称監査、業界カテゴリ監査、アバター及びプロファイル監査、（推奨・検索）材料監査、支払いアカウント監査などを含むが、これらに限られない。

ステップ２０２において、監査プラットフォームが返送した監査任務識別子に基づいて報知待ちメッセージを生成する。

ただし、監査任務識別子は、監査プラットフォームがビジネス監査要求に対して割り当てる識別子である。

一部の実施例において、監査プラットフォームは、ゲートウェイのビジネス監査要求を受信した後、ゲートウェイに監査任務識別子を返送する。ゲートウェイは、監査任務識別子を受信した後、報知待ちメッセージを生成する。

一部の実施例において、報知待ちメッセージが報知待ちメッセージライブラリに記憶されており、報知待ちメッセージに係るフィールドは、監査任務識別子、ユーザ身元識別子、ビジネス監査提出時間、監査報知テンプレート、操作パラメータ及び監査結果メッセージ項目を含む。

ただし、監査報知テンプレートは、事前に配置されてもよく、操作タイプごとに監査報知テンプレートが個別に配置される。それぞれの監査報知テンプレートは、監査通過サブテンプレート及び監査拒絶サブテンプレートを含んでもよい。

一部の実施例において、監査報知テンプレートは、ｊｓｏｎ構成を採用してもよく、例えば、ミニアプリパッケージの監査拒絶サブテンプレートは、以下のフォーマットを採用してもよい。

ただし、${…}のような形の文字列は、書き込み対象フィールドを表す。書き込み対象フィールドは、提出された要求パラメータ及び監査結果メッセージから、対応するフィールド値を抽出して書き込むことができる。例えば、ａｐｐ_ｉｄは、ミニアプリ識別子ＩＤを表し、ｄｅｖｅｌｏｐｅｒ_ｉｄ及びｔｐ_ｄｅｖｅｌｏｐｅｒ_ｉｄは、それぞれ開発者識別子ＩＤ及び第３者の事業者識別子ＩＤを表し、ｒｅａｓｏｎフィールドは、監査失敗原因を表し、ｐａｃｋａｇｅ_ｉｄ及びｐａｃｋａｇｅ_ｖｅｒｓｉｏｎは、それぞれミニアプリパッケージ識別子ＩＤ及びミニアプリパッケージバージョンを表す。

ステップ２０３において、取得された監査結果及び報知待ちメッセージに基づいて監査報知メッセージを生成する。

ただし、監査結果は、監査通過及び監査拒絶を含む。例えば、監査プラットフォームは、ミニアプリ能力が設定された要求に合致すると認定した場合、監査結果が監査通過になる。監査プラットフォームは、ミニアプリ能力が設定された要求に合致しないと認定した場合、監査結果は監査拒絶になる。

一部の実施例において、監査プラットフォームは監査員により監査プラットフォームのページ上で人工監査を行う。監査員はミニアプリ能力が設定された要求を満たすと認定した場合、監査結果が監査通過になる。監査員はミニアプリ能力が設定された要求を満たさないと認定した場合、監査結果が監査拒絶になる。

一部の実施例において、ゲートウェイは、監査結果と報知待ちメッセージとを組み合わせて、監査報知メッセージを生成する。例えば、ゲートウェイは、監査結果を取得した後、監査結果を報知待ちメッセージの対応するフィールドに加えて、監査報知メッセージを取得する。

例えば、監査報知メッセージは、以下のようなフォーマットを採用することができる。

ただし、ミニアプリの識別子は「１４５２３６５」であり、開発者識別子は「１７３２８２３２」であり、監査提出時間は「２０１９-０１-１４ １２:４５:１０」であり、監査のタイプは「ＰＡＣＫＡＧＥ_ＡＵＤＩＴ_ＦＡＩＬ」であり、監査失敗の原因は「名称と実際に開いた後の名称とが一致していない」であり、ミニアプリパッケージの識別子は「７４５８１５」であり、ミニアプリパッケージのバージョンは「１.３.４６」である。

ステップ２０４において、監査報知メッセージをユーザ端末にプッシュする。

ゲートウェイは、監査報知メッセージを生成した後、監査報知メッセージをユーザ端末にプッシュして、ユーザがユーザ端末により監査結果を見る。

一部の実施例において、図３に示すように、ユーザの操作要求に応答して監査プラットフォームにビジネス監査要求を送信することは、操作要求を解析してユーザ身元識別子及びミニアプリ識別子を取得するステップ３０１を含む。

一部の実施例において、ゲートウェイは、操作要求を受信した後、操作要求を解析して、ユーザ身元、ミニアプリ識別子、操作タイプ及び操作パラメータを取得する。

ただし、操作タイプは、ミニアプリパッケージ管理、基本情報設置、情報流れ・材料検索サービス、注文・支払いサービス及びメッセージサービスを含むが、これらに限られない。操作パラメータは、操作タイプに関連しており、それぞれの操作タイプが異なるパラメータに対応する。

例えば、ユーザ端末が発した操作要求は、ミニアプリ名称を修正する要求であれば、操作要求にユーザ身元識別子、ミニアプリ識別子、操作タイプ（名称修正）及び名称パラメータ（ミニアプリの新しい名称）が含まれる。

一部の実施例において、操作パラメータは、第３者の事業者に対する承認時間を標記するためのタイムスタンプをさらに含み、即ち、第３者の事業者は承認時間内でミニアプリを開発、修正することができる。

ステップ３０２において、ユーザ身元識別子及びミニアプリ識別子に基づいてユーザ身元を検証する。

一部の実施例において、ユーザ身元識別子及びミニアプリ識別子に基づいてユーザ身元を認証する。例えば、ゲートウェイは、ユーザ身元識別子に基づいてミニアプリ識別子との権限関係を検証する。このユーザがこのミニアプリ識別子に対応するミニアプリに対する操作権限を持っていない場合、直接にユーザ端末に無権限メッセージを返送する。このユーザがこのミニアプリ識別子に対応するミニアプリに対する操作権限を持っている場合、後続操作を行う。

ステップ３０３において、ユーザ身元に対する検証が成功した場合、監査プラットフォームにビジネス監査要求を送信する。

ユーザ身元に対する検証が成功した場合、ゲートウェイは、監査プラットフォームにビジネス監査要求を送信する。ビジネス監査要求には、ミニアプリ識別子、操作タイプ（名称修正）及び名称パラメータ（ミニアプリの新しい名称）が含まれる。

一部の実施例において、監査プラットフォームは、ビジネス監査要求を受信した後、ゲートウェイに監査任務識別子ＩＤを返送し、ゲートウェイが監査任務識別子を受信した後、報知テンプレートライブラリから操作タイプに対応する監査報知テンプレートを取得し、監査報知テンプレート、監査任務識別子に基づいて、報知待ちメッセージを生成し、報知待ちメッセージを報知待ちメッセージライブラリに記憶する。ただし、報知待ちメッセージは、監査任務識別子、ユーザ身元識別子、ビジネス監査提出時間、監査報知テンプレート、操作パラメータ及び監査結果メッセージ項目を含む。

一部の実施例において、監査報知テンプレートは、報知テンプレートライブラリに予め設置され、記憶されているテンプレートである。ただし、それぞれの操作タイプは、１つの監査報知テンプレートに対応する。監査報知テンプレートは、操作タイプに応じて特定されたテンプレートであり、汎用性がある。監査報知テンプレートを報知テンプレートライブラリに記憶して、必要な時に監査報知テンプレートを随時に抽出することで、報知待ちメッセージの生成の効率を向上することでき、そして、エラーの確率を低減することができる。

ゲートウェイは、操作要求を受信した後、操作要求のタイプに基づいて、監査報知テンプレートライブラリを照会して、それと整合する監査報知テンプレートを取得し、さらに監査任務識別子、ユーザ身元識別子、ビジネス監査提出時間、監査報知テンプレート、操作パラメータ及び監査結果メッセージ項目に基づいて、報知待ちメッセージを生成する。

一部の実施例において、監査プラットフォームは、ビジネス監査要求における監査待ち内容を監査した後、監査結果をメッセージキューに送信する。ただし、メッセージキューは、監査結果を記憶するための行列であり、メッセージキューにおける各メッセージは、いずれも監査任務識別子及び監査結果を含む。

一部の実施例において、同一監査結果は、１回でマルチプッシュされることがあり得る。例えば、ミニアプリ開発者と第３者の事業者との両方は、監査結果を取得する必要がある場合、この監査結果がミニアプリの開発者に送信されるだけではなく、第３者の事業者に送信されてもよい。メッセージキューを利用してゲートウェイと監査プラットフォームとを隔離し、１回の監査結果を多方向にプッシュして消費する目的を実現することができる。

一部の実施例において、ゲートウェイは、メッセージキューから監査結果を申し込んで、監査結果及び報知待ちメッセージを組み合わせて監査報知メッセージを取得する。

例えば、ゲートウェイは、監査任務識別子に従ってメッセージキューから監査結果を取得し、報知待ちメッセージライブラリから報知待ちメッセージを取得し、監査結果を報知待ちメッセージにおける監査結果メッセージ項目に組み込むことで、監査報知メッセージを取得する。

実際の応用において、監査報知メッセージを失った状況が現れると、ユーザ端末に監査報知メッセージを再度プッシュする必要がある。監査結果をメッセージキューに記憶することで、ゲートウェイは、メッセージキューから監査結果を複数回申し込んで、ユーザ端末に監査報知メッセージを複数回プッシュすることを実現し、プッシュ漏れの問題を効果的に回避することができる。

一部の実施例において、ユーザ端末は、ネットワーク故障などの原因で監査報知メッセージを受信できないことがあるため、ゲートウェイは、所定の時間間隔、所定のプッシュ回数に従ってユーザ端末に監査報知メッセージを複数回プッシュすることができる。例えば、所定の最大プッシュ回数は５回であり、所定の時間間隔は１分、５分、１５分、１時間又は６時間である。ゲートウェイは、ユーザ端末に監査報知メッセージを初回にプッシュした後、１分の間隔で第１回の補足プッシュを行い、第１回の補足プッシュを完了した後、５分の間隔で第２回の補足プッシュを行い、第２回の補足プッシュを完了した後、１５分の間隔で第３回の補足プッシュを行い、第３回の補足プッシュを完了した後、１時間の間隔で第４回の補足プッシュを行い、第４回の補足プッシュを完了した後、６時間の間隔で第５回の補足プッシュを行う。プッシュ回数及びプッシュ時間間隔を設定することで、プッシュの成功率を向上することができる。

一部の実施例において、図４に示すように、監査報知メッセージをユーザ端末にプッシュすることは、
プッシュアドレスライブラリからユーザ端末のプッシュアドレスを取得するステップ４０１を含む。

ただし、プッシュアドレスライブラリは、プッシュアドレスを記憶するデータベースである。ユーザ端末のアドレスは、プッシュアドレスライブラリ内に記憶されていることで、ゲートウェイがプッシュアドレスに従ってユーザ端末に監査報知メッセージをプッシュしやすくなる。

一部の実施例において、ユーザは、ユーザ端末により自分のアドレスをプッシュアドレスライブラリに予め記憶して、ゲートウェイにより必要な時にプッシュアドレスライブラリから呼び出されることに供する。

ステップ４０２において、プッシュアドレスに従って監査報知メッセージをユーザ端末にプッシュする。

ゲートウェイは、監査任務識別子に従ってメッセージキューから対応する監査結果を申し込み、監査任務識別子に従って報知待ちメッセージライブラリから対応する報知待ちメッセージを取得し、この監査任務識別子に対応する監査結果及び報知待ちメッセージを組み合わせて、監査報知メッセージを取得する。ゲートウェイは、プッシュアドレスライブラリからユーザ端末のプッシュアドレスを取得し、プッシュアドレスに従って監査報知メッセージをユーザ端末に送信する。

一部の実施例において、ゲートウェイは、プッシュアドレスに従ってユーザ端末に監査報知メッセージを複数回プッシュして、プッシュの成功率を向上することができる。

一部の実施例において、報知待ちメッセージライブラリにおける報知待ちメッセージが長い時間にわたって監査結果の記録がない場合、ゲートウェイは、直接に監査プラットフォームを照会して、監査結果を取得し、監査結果と報知待ちメッセージとを組み合わせてからユーザ端末にプッシュし、それによりメッセージのプッシュ漏れを回避する。

本実施例が提供したビジネス監査報知方法は、ユーザ端末が発した操作要求に応答して監査プラットフォームにビジネス監査要求を送信し、監査プラットフォームが返送した監査任務識別子に基づいて報知待ちメッセージを生成し、監査結果を取得して、監査結果及び報知待ちメッセージに基づいて監査報知メッセージを生成し、監査報知メッセージをユーザ端末にプッシュする。この方法は、任意のミニアプリ能力の非同期報知メカニズムをサポートできるとともに、開発者の人力コストを低減し、コード冗長性を低下させ、かつビジネスコードのメンテナンス性を向上した。

第２の態様において、本願の実施例は、ビジネス監査報知方法を提供し、この方法が監査プラットフォームに適用される。

図５は、本願の実施例が提供したビジネス監査報知方法のフローチャートである。図５を参照して、本願の実施例は、ビジネス監査報知方法を提供し、
ビジネス監査要求を受信するステップ５０１を含む。

ただし、ビジネス監査要求は、ゲートウェイがユーザ端末により発された操作要求に応答して送信した要求である。

一部の実施例において、ゲートウェイは、ユーザ端末より発された操作要求を受信した後、監査プラットフォームにビジネス監査要求を発す。ただし、操作要求は、ミニアプリの基本情報（例えば、名称、アバター、プロファイル、業界カテゴリなど）の修正、ミニアプリパッケージのリリース、配信材料提出（検索・推奨ｆｅｅｄ）及び支払いサービス開通などを含むが、これらに限られない。ビジネス監査要求は操作要求に基づき、即ち、ビジネス監査要求は操作要求に対応しており、ビジネス監査要求のタイプはミニアプリパッケージ監査、名称監査、業界カテゴリ監査、アバター及びプロファイル監査、（ｆｅｅｄ・検索）材料監査及び支払いアカウント監査などを含む。

ステップ５０２において、監査結果を取得して記憶して、ゲートウェイが監査結果及び報知待ちメッセージに基づいて監査報知メッセージを生成するために供する。

ただし、報知待ちメッセージは、ゲートウェイがビジネス監査要求に対して生成したメッセージである。

一部の実施例において、監査プラットフォームは、監査人員によって監査するため、監査プラットフォームがビジネス監査要求を受信した後、表示装置によって監査人員にビジネス監査要求を表示することができる。監査人員は、ビジネス監査要求における監査タイプを監査して、関連規定に合致する監査タイプに対して監査通過を下し、関連規定に合致しない監査タイプに対して監査拒絶を下す。

一部の実施例において、監査プラットフォームは、監査人員の監査結果を取得した後、監査結果をメッセージキューに送信して、ゲートウェイが必要な時に監査結果を取得し、又はメッセージキューが主動的に監査結果をゲートウェイにプッシュすることに供する。

一部の実施例において、監査プラットフォームは、ビジネス監査要求を受信した後、ゲートウェイに監査任務識別子を返送し、ただし、監査任務識別子は監査任務の唯一の識別子であり、後続のステップにおいて、ゲートウェイが監査任務識別子で報知待ちメッセージ及び監査結果を取得する。

例えば、ゲートウェイは、監査任務識別子に従ってメッセージキューから対応する監査結果を申し込み、監査任務識別子に従って報知待ちメッセージライブラリから対応する報知待ちメッセージを取得し、監査結果と報知待ちメッセージとを組み合わせて、監査報知メッセージを取得する。

本実施例が提供したビジネス監査報知方法は、ビジネス監査要求を受信し、監査結果を受信し、監査結果を記憶して、ゲートウェイが監査結果及び報知待ちメッセージに基づいて監査報知メッセージを生成することに供し、監査報知メッセージをユーザ端末にプッシュする。この方法は、任意のビジネス監査の非同期報知メカニズムをサポートできるとともに、開発人員の人力コストを低減し、コード冗長性を低下させ、ビジネスコードのメンテナンス性を向上した。

第３の態様において、本願の実施例は、ゲートウェイを提供した。図６は、本願の実施例が提供したゲートウェイの原理ブロック図である。

図６を参照して、本願の実施例が提供したゲートウェイは、
ユーザ端末の操作要求に応答して監査プラットフォームにビジネス監査要求を送信し、監査プラットフォームにより返送された監査任務識別子に基づいて報知待ちメッセージを生成するように配置されている提出モジュール６０１と、
取得された監査結果及び報知待ちメッセージに基づいて監査報知メッセージを生成し、監査報知メッセージをユーザ端末にプッシュするように配置されているプッシュモジュール６０２とを含む。

一部の実施例において、監査結果がメッセージキューから取得される。監査プラットフォームは、監査結果を取得した後、監査結果をメッセージキューに格納して、メッセージキューが監査結果を受信した後、監査結果をプッシュモジュール６０２に伝送する。或いは、プッシュ手段６０２は、所定の条件に従って主動的にメッセージキューから監査結果を抽出してもよい。例えば、抽出の時間を毎日８:００～１８:００に予め設置して、抽出の時間間隔が３０分であり、プッシュ手段６０２は、この所定時間及び時間間隔に従って監査結果を抽出する。

一部の実施例において、図７に示すように、提出モジュール７００は、
監査プラットフォームにビジネス監査要求を送信するように配置されている監査提出手段７０１を含む。

一部の実施例において、監査提出手段７０１は、ユーザ端末により発された操作要求に基づいて監査プラットフォームにビジネス監査要求を送信する。

ただし、ユーザ端末は、ミニアプリ開発者又は第３者の事業者が使用するミニアプリを開発する端末である。ユーザは、例えば、ミニアプリパッケージ管理、基本情報設置、情報流れ・材料検索サービス、注文・支払いサービス、メッセージサービスなどのミニアプリ能力を豊富にするために、ミニアプリを開発し、或いは修正する。すべての開発及び修正は、監査プラットフォームを介して監査される必要がある。

ただし、操作要求は、ミニアプリの基本情報（例えば、名称、アバター、プロファイル、業界カテゴリなど）の修正、ミニアプリパッケージのリリース、配信材料の提出（検索・推奨ｆｅｅｄ）及び支払いサービスの開通などを含むが、これらに限られない。

ただし、ビジネス監査要求は、操作要求に対するものであり、操作要求に応じて、異なる操作要求は、異なるビジネス監査要求に対応している。ビジネス監査要求は、ミニアプリパッケージ監査、名称監査、業界カテゴリ監査、アバター及びプロファイル監査、（推奨・検索）材料監査、支払いアカウント監査などを含むが、これらに限られない。

第１の生成手段７０２は、監査プラットフォームにより返送された監査任務識別子に基づいて報知待ちメッセージを生成するように配置されている。

一部の実施例において、監査プラットフォームは、ゲートウェイのビジネス監査要求を受信した後、ゲートウェイに監査任務識別子を返送する。ただし、監査任務識別子は、監査プラットフォームがビジネス監査要求のために割り当てる識別子である。ゲートウェイが監査任務識別子を受信した後、第１の生成手段７０２が報知待ちメッセージを生成する。

一部の実施例において、第１の生成手段７０２は、操作要求のタイプに基づいて監査報知テンプレートを取得し、ユーザ身元識別子、監査任務識別子、ビジネス監査提出時間、監査報知テンプレート、操作パラメータ及び監査結果メッセージ項目に基づいて、報知待ちメッセージを生成する。

ただし、ユーザ身元識別子は、ユーザ身元を示す唯一の識別子である。ビジネス監査提出時間は、監査提出手段が監査プラットフォームに監査任務を提出する時間である。監査報知テンプレートは、事前に配置されてもよく、各種の操作タイプは、報知テンプレートを個別に配置する。各種の報知テンプレートは、監査通過サブテンプレート及び監査拒絶サブテンプレートを含んでもよい。操作パラメータは、操作要求における要求内容であり、操作タイプによって操作パラメータが異なる。例えば、ミニアプリパッケージをリリースする場合、ミニアプリパッケージ識別子（ｐａｃｋａｇｅ_ｉｄ）及びミニアプリパッケージバージョン（ｐａｃｋａｇｅ_ｖｅｒｓｉｏｎ）パラメータを提供する必要があり、ミニアプリ名称を修正する場合、ミニアプリ名称（ａｐｐ_ｎａｍｅ）パラメータを提供する必要がある。監査結果メッセージ項目は、監査結果を書き込むための項目である。第１の生成手段７０２により生成された報知待ちメッセージのうち、監査結果メッセージ項目は空きである。

一部の実施例において、提出モジュール６０１は、ユーザ端末の身元を認証するように配置されている認証手段をさらに含む。

図８に示すように、認証手段８００は、
操作要求を解析して、ユーザ身元識別子及びミニアプリ識別子を取得するように配置されている解析サブ手段８０１を含む。

一部の実施例において、操作要求には、ユーザ身元識別子及びミニアプリ識別子が含まれており、解析サブ手段８０１は、操作要求を解析することで、ユーザ身元識別子及びミニアプリ識別子を取得することができる。

検証サブ手段８０２は、ユーザ身元識別子及びミニアプリ識別子に基づいて、ユーザ身元を検証するように配置されている。

一部の実施例において、検証サブ手段８０２は、ユーザ身元識別子に基づいてミニアプリ識別子との権限関係を検証する。このユーザがこのミニアプリ識別子に対応するミニアプリに対する操作権限を持っていない場合、ユーザ端末に無権限メッセージを直接返送し、このユーザがこのミニアプリ識別子に対応するミニアプリに対する操作権限を持っている場合、後続の操作を行う。

図９に示すように、プッシュモジュール９００は、
取得された監査結果及び報知待ちメッセージに基づいて、監査報知メッセージを生成するように配置されている第２の生成手段９０１を含む。

ただし、監査結果は、監査通過及び監査拒絶を含む。監査標準に合致する場合、監査プラットフォームは監査通過の監査結果を得て、監査標準に合致しない場合、監査プラットフォームは監査拒絶の監査結果を得る。

一部の実施例において、第２の生成手段９０１は、監査結果を取得した後、監査結果を報知待ちメッセージにおける監査報知メッセージ項目に書き込み、監査報知メッセージを生成する。

プッシュ手段９０２は、監査報知メッセージをユーザ端末にプッシュするように配置されている。

一部の実施例において、プッシュ手段９０２は、プッシュアドレスライブラリから開発者又は第３者の事業者のアドレスを取得し、監査報知メッセージを開発者又は第３者の事業者にプッシュする。

一部の実施例において、図１０に示すように、プッシュモジュール１０００は、第２の生成手段１００１、プッシュ手段１００２及び申し込み手段１００３を含み、ただし、第２の生成手段１００１及びプッシュ手段１００２の原理及び機能は、第２の生成手段９０１及びプッシュ手段９０２と同様であり、ただし説明を繰り返さない。

申し込み手段１００３は、メッセージキューから監査結果を申し込み、監査結果を第２の生成手段に伝送するように配置されている。

説明しておくことは、メッセージキューが監査結果を記憶するための行列である。メッセージキューは、監査プラットフォームに設置されてもよく、ゲートウェイに設置されてもよく、監査プラットフォーム及びゲートウェイから独立して設置されてもよい。メッセージキューを利用して監査プラットフォームとゲートウェイとをデカップリングすることで、１回のプッシュで複数の箇所で消費される目的を実現する。

一部の実施例において、ゲートウェイは、監査報知テンプレートを記憶するように配置されている報知テンプレートライブラリ１００４をさらに含む。監査報知テンプレートは、報知テンプレートライブラリ１００４に予め配置されて記憶されていてもよい。監査報知テンプレートは、操作要求のタイプと整合し、そして、それぞれの操作タイプは、２つの監査報知テンプレート、即ち、監査通過テンプレート及び監査拒絶テンプレートに対応する。監査通過テンプレート及び監査拒絶テンプレートの設置形式は、本願の方法部分で言及されており、ただし説明を繰り返さない。

説明しておくことは、報知テンプレートライブラリ１００４は、ゲートウェイに設置されてもよく、ゲートウェイから独立した他の手段又はモジュールに設置されてもよく、報知テンプレートを記憶でき、かつ提出モジュール及びプッシュモジュールがこの報知テンプレートライブラリにアクセスできるようにすればよい。

プッシュアドレスライブラリ１００５は、ユーザ端末のプッシュアドレスを記憶するように配置されている。ただし、プッシュアドレスは、ユーザにより予め配置される報知を受信するアドレスである。

一部の実施例において、ミニアプリ開発者及び第３者の事業者は、それぞれのアドレスをプッシュアドレスライブラリに予め設置してもよく、それにより、プッシュモジュールが必要な場合に、ミニアプリ開発者又は第３者の事業者のアドレスを取得しやすくなる。

説明しておくことは、プッシュアドレスライブラリ１００５は、ゲートウェイに設置されてもよく、ゲートウェイから独立した他の手段又はモジュールに設置されてもよく、アドレスを記憶でき、かつ提出モジュール及びプッシュモジュールがこのプッシュアドレスライブラリにアクセスできるようにすればよい。

本実施例が提供したゲートウェイは、提出モジュールを利用して、ユーザ端末の操作要求を受信した場合、監査プラットフォームにビジネス監査要求を送信し、監査プラットフォームより返送された監査任務識別子に基づいて、報知待ちメッセージを生成し、プッシュモジュールにより取得された監査結果及び報知待ちメッセージを利用して、監査報知メッセージを生成し、監査報知メッセージをユーザ端末にプッシュする。このゲートウェイは、汎用性があり、任意タイプのビジネス監査（例えば、ミニアプリ能力の監査）をサポートできるとともに、開発人員の人力コストを低減し、コード冗長性を低下させ、かつビジネスコードのメンテナンス性を向上した。

第４の態様において、本願の実施例は、監査プラットフォームを提供し、この監査プラットフォームは、アプリケーションプログラムのビジネス、例えば、ミニアプリのビジネスを監査することができる。

図１１は、本願の実施例が提供した監査プラットフォームの原理ブロック図である。図１１に示すように、監査プラットフォーム１１００は、
ビジネス監査要求を受信するように配置されている受信モジュール１１０１を含む。

ただし、ビジネス監査要求は、ゲートウェイがユーザ端末の操作要求に応答して送信したメッセージである。

取得モジュール１１０２は、監査結果を取得するように配置されている。

一部の実施例において、監査プラットフォームは、監査人員によって人工監査を行う。監査結果は、監査人員が監査要求を監査した結果である。例えば、監査プラットフォームは、監査人員に監査要求、即ち、監査要求における監査事項を表示し、監査人員は、監査事項を監査し、監査結果を得て、この監査結果を監査プラットフォームに伝送する。

一部の実施例において、監査プラットフォームは、他の態様によって監査してもよく、例えば、人工と機器とを結合する態様によって監査してもよい。

記憶モジュール１１０３は、監査結果を記憶するように配置されている。

一部の実施例において、記憶モジュール１１０３は、メッセージキューの形で監査結果を記憶する。記憶モジュール１１０３は、監査プラットフォームに設置されてもよく、監査プラットフォームから独立した他のモジュール又は手段に設置されてもよい。

一部の実施例において、監査プラットフォームは、さらに、
ゲートウェイに監査任務識別子を返送するように配置されている任務識別子生成モジュールを含む。ただし、監査任務識別子は、監査任務の唯一の識別子である。

本願の実施例が提供した監査プラットフォームは、受信モジュールを利用してビジネス監査要求を受信し、取得モジュールを利用して監査結果を取得し、記憶モジュールを利用して監査結果を記憶する。この監査プラットフォームは、任意タイプのビジネスを監査してもよく、そして、ゲートウェイ開発人員の人力コストを低減し、コード冗長性を低減させ、かつビジネスコードのメンテナンス性を向上することができる。

本願の実施例が提供したビジネス監査報知方法がよりよく理解されるために、以下、ユーザ端末、ゲートウェイ及び監査プラットフォームを合わせて、ビジネス監査報知方法をさらに紹介する。

図１２は、本実施例が提供したビジネス監査報知方法のフローチャートである。図１２に示すように、ビジネス監査報知方法は、
ユーザ端末がゲートウェイの提出モジュールに操作要求を送信するステップ１２０１を含む。

ただし、操作要求は、ユーザ身元識別子、ミニアプリ識別子、操作タイプ（名称修正）及び名称パラメータ（ミニアプリの新しい名称）を含む。

ステップ１２０２において、ゲートウェイは、ユーザ身元を認証する。

本実施例において、ゲートウェイは、操作要求からユーザ身元識別子、ミニアプリ識別子を解析し、ユーザ身元識別子に基づいてミニアプリ識別子との権限関係を検証する。ユーザ身元識別子が操作権限を持っていない場合、ユーザ端末に検証失敗メッセージを返送する。ユーザ身元識別子が操作権限を持っている場合、ユーザ端末に検証成功メッセージを返送し、後続のステップを実行し、又は、ユーザ端末に検証成功メッセージを返送せずに、直接に後続のステップを実行する。

ステップ１２０３において、ゲートウェイの監査提出手段は、監査プラットフォームにビジネス監査任務を送信する。

ビジネス監査任務は、ゲートウェイが操作要求に基づいて得られた監査任務である。ビジネス監査任務は、ミニアプリ識別子、操作タイプ（名称修正）及び名称パラメータを含む。ユーザ身元に対する検証が成功した場合、ゲートウェイは、監査プラットフォームにビジネス監査要求を送信する。

ステップ１２０４において、監査プラットフォームは、ゲートウェイに監査任務識別子を返送する。

本実施例において、監査プラットフォームは、ビジネス監査任務を受信した後、このビジネス監査任務のために１つの唯一の識別子を割り当てって、後続のフローで使用されることに供する。

ステップ１２０５において、ゲートウェイは、報知テンプレートライブラリから監査報知テンプレートを取得する。

本実施例において、監査報知テンプレートは、開発者又は第３者の事業者により予め設定され、報知テンプレートライブラリに記憶されているテンプレートである。

ステップ１２０６において、監査任務識別子、ユーザ身元識別子、ビジネス監査提出時間、監査報知テンプレート、操作パラメータ及び監査結果メッセージ項目に基づいて、報知待ちメッセージを生成する。

本実施例において、ゲートウェイは、監査プラットフォームより返送された監査任務識別子に基づいて、報知テンプレートライブラリから監査報知テンプレートを取得し、ユーザ端末により送信されたユーザ身元識別子、ビジネス監査提出時間及び操作パラメータ、並びに監査結果メッセージ項目を合わせて、報知待ちメッセージを生成する。

ステップ１２０７において、監査プラットフォームは、監査人員の監査結果を受信する。

本実施例において、監査プラットフォームは、監査人員に操作パラメータを表示し、監査人員は、操作パラメータに従ってビジネス監査要求を監査し、監査結果を監査プラットフォームに伝送する。

ステップ１２０８において、監査プラットフォームは、監査結果をメッセージキューに記憶する。

ステップ１２０９において、ゲートウェイは、メッセージキューから監査結果を取得する。

ステップ１２１０において、ゲートウェイは、監査任務識別子に基づいて、報知待ちメッセージライブラリから対応する報知待ちメッセージを取得し、監査結果及び報知待ちメッセージを組み合わせて、報知メッセージを取得する。

ステップ１２１１において、ゲートウェイは、プッシュアドレスライブラリからユーザ端末のプッシュアドレスを取得する。

本実施例において、ユーザ端末のプッシュアドレスは、ユーザによりプッシュアドレスライブラリに予め配置されたものである。

ステップ１２１２において、ゲートウェイは、報知メッセージをプッシュアドレスに従ってユーザ端末にプッシュする。

本願の実施例によれば、本願は、電子機器及び読取可能な記憶媒体をさらに提供した。

図１３は、本願の実施例によるビジネス監査報知の方法の電子機器のブロック図である。図１３に示すように、電子機器とは、様々な形式のデジタルコンピュータ、例えば、ラップトップ型コンピュータと、デスクトップコンピュータと、ワークステーションと、パーソナル・デジタル・アシスタントと、サーバと、ブレードサーバと、大型コンピュータと、他の適宜なコンピュータとを表す旨である。電子機器は、様々な形式の移動装置、例えば、パーソナル・デジタル・アシスタントと、セルラー電話と、スマートフォンと、ウェアラブル機器と、他の類似する計算装置とを表してもよい。本明細書に示す部品と、それらの接続及び関係と、それらの機能とは単に例示であり、本明細書で説明した及び／又は要求した本願の実現を限定することを意図しない。

図１３に示すように、この電子機器は、１つ又は複数のプロセッサ１３０１、メモリ１３０２、及び各部品を接続するための、高速インターフェース及び低速インターフェースを含むインターフェースを備える。各部品は、異なるバスで互いに接続され、且つ共通のメインボード上に実装されてもよく、又は必要に応じて他の方式で実装されてもよい。プロセッサは、電子機器内で実行されるコマンドを処理することができ、メモリに記憶されて、外部入力・出力装置（例えば、インターフェースに結合する表示機器）上に図形ユーザインターフェース（Ｇｒａｐｈｉｃａｌ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ，ＧＵＩ）の図形情報を表示するコマンドを含む。他の実施形態においては、必要に応じて、複数のプロセッサ及び／又は複数のバスを複数のメモリと一緒に使用してもよい。同様に、複数の電子機器を接続して、各機器が一部の必要な操作を提供してもよい（例えば、サーバアレー、一組のブレードサーバ、又はマルチプロセッサシステムとする）。図１３においては、１つのプロセッサ１３０１を例とする。

メモリ１３０２は、本願が提供した非一時的なコンピュータ読取可能な記憶媒体である。ただし、前記メモリには少なくとも１つのプロセッサにより実行され得るコマンドが記憶されており、前記少なくとも１つのプロセッサに本願が提供したビジネス監査報知の方法を実行させる。本願の非一時的なコンピュータ読取可能な記憶媒体は、コンピュータコマンドを記憶しており、このコンピュータコマンドは、コンピュータに本願が提供したビジネス監査報知の方法を実行させるものである。

メモリ１３０２は、非一時的なコンピュータ読取可能な記憶媒体として、非一時的なソフトウェアプログラム、非一時的なコンピュータ実行可能なプログラム及びモジュール、例えば本願の実施例におけるビジネス監査報知の方法に対応するプログラムコマンド・モジュールを記憶するものである。プロセッサ１３０１は、メモリ１３０２に記憶されている非一時的なソフトウェアプログラム、コマンド及びモジュールを実行することで、サーバの各種の機能アプリケーション及びデータ処理を実行し、即ち上記方法実施例におけるビジネス監査報知の方法を実現する。

メモリ１３０２は、プログラム記憶領域及びデータ記憶領域を含んでもよく、ただし、プログラム記憶領域は、オペレーティングシステム、少なくとも１つの機能に必要なアプリケーションプログラムを記憶してもよく、データ記憶領域は、ビジネス監査報知による電子機器の使用により生成されたデータなどを記憶してもよい。また、メモリ１３０２は、高速ランダムアクセスメモリを含んでもよく、非一時なメモリ、例えば少なくとも１つの磁気ディスク記憶デバイス、フラッシュメモリデバイス、又は他の非一時的なソリッド記憶デバイスを含んでもよい。一部の実施例において、メモリ１３０２は選択的にプロセッサ１３０１に対して遠隔に設置されたメモリを含み、これらの遠隔メモリが、ネットワークを介して電子機器に接続されてもよい。上記ネットワークの例示は、インターネット、イントラネット、ローカルエリアネットワーク、移動通信ネットワーク及びそれらの組合を含むが、これらに限られない。

ビジネス監査報知の方法の電子機器は、入力装置１３０３及び出力装置１３０４をさらに含んでもよい。プロセッサ１３０１、メモリ１３０２、入力装置１３０３及び出力装置１３０４は、バス又は他の方式で接続されてもよく、図１３においてバスを介して接続されることを例とする。

入力装置１３０３は、入力されたデジタル又はキャラクター情報を受信し、ビジネス監査報知方法の電子機器のユーザ設置及び機能制御に関わるキー信号入力を発生してもよく、例えば、タッチスクリーン、キーパッド、マウス、トラックパッド、タッチパッド、インジケーターロッド、１つ又は複数のマウスボタン、トラックボール、レバーなどの入力装置である。出力装置１３０４は、表示デバイスと、補助照明装置（例えば、ＬＥＤ）と、触覚フィードバック装置（例えば、振動モーター）などを含んでもよい。この表示デバイスは、液晶ディスプレー（ＬＣＤ）と、発光ダイオード（ＬＥＤ）ディスプレーと、プラズマディスプレーとを含むが、これらに限られない。一部の実施形態において、表示デバイスはタッチスクリーンであってもよい。

ただし説明したシステム及び技術の各実施形態は、デジタル電子回路システム、集積回路システム、専用ＡＳＩＣ（専用集積回路）、コンピュータハードウェア、ファームウェア、ソフトウェア、及び／又はそれらの組合せで実現されてもよい。これらの各実施形態は、１つ又は複数のコンピュータプログラムで実施されることを含んでもよく、この１つまたは複数のコンピュータプログラムが、少なくとも１つのプログラマブルプロセッサを含むプログラマブルシステム上で実行及び／又は解釈されてもよく、このプログラマブルプロセッサは、専用又は共通のプログラマブルプロセッサであってもよく、記憶システムと、少なくとも１つの入力装置と、少なくとも１つの出力装置とからデータと命令とを受信し、データと命令とをこの記憶システムと、この少なくとも１つの入力装置と、この少なくとも１つの出力装置とに伝送してもよい。

これらの計算プログラム（プログラム、ソフトウェア、ソフトウェアアプリケーション、又はコードとも称する）は、プログラマブルプロセッサの機械命令を含み、高級プロセス及び／又はオブジェクト指向のプログラミング言語、及び／又はアセンブリ・機械言語によってこれらの計算プログラムを実施してもよい。本明細書で使用した術語「機械読取可能な媒体」及び「コンピュータ読取可能な媒体」とは、機械命令及び／又はデータをプログラマブルプロセッサに提供するための任意のコンピュータプログラム製品、機器、及び／又は装置（例えば、磁気ディスク、光ディスク、メモリ、プログラマブルロジックデバイス（ＰＬＤ））を意味しており、機械読取可能な信号である機械命令を受ける機械読取可能な媒体を含む。術語「機械読取可能な信号」とは、機械命令及び／又はデータをプログラマブルプロセッサに提供するための任意の信号を意味している。

ユーザとのインタラクションを提供するために、コンピュータでただし説明したシステム及び技術を実施してもよく、このコンピュータは、ユーザに情報を表示するための表示装置（例えば、ＣＲＴ（陰極線管）又はＬＣＤ（液晶ディスプレー）モニタ）と、キーボード及び指向装置（例えば、マウス又はトラックボール）とを有し、ユーザは、このキーボード及びこの指向装置によって、入力をコンピュータに提供することができる。他の種類の装置は、ユーザとのインタラクションを提供するためのものであってもよく、例えば、ユーザに提供するフィードバックは、任意の形式のセンサーフィードバック（例えば、視覚フィードバック、聴覚フィードバック、又は触覚フィードバック）であってもよく、任意の形式（声入力、語音入力、又は触覚入力を含む）でユーザからの入力を受信してもよい。

ただし説明したシステム及び技術は、バックグラウンド部品を含む計算システム（例えば、データサーバとする）、又はミドルウェア部品を含む計算システム（例えば、アプリケーションサーバ）、又はフロントエンド部品を含む計算システム（例えば、グラフィカル・ユーザー・インターフェース又はネットワークブラウザを有するユーザコンピュータ、ユーザはこのグラフィカル・ユーザー・インターフェース又はこのネットワークブラウザを介してただし説明したシステム及び技術の実施形態とインタラクトすることができる）、又はこのようなバックグラウンド部品、ミドルウェア部品、或いはフロントエンド部品の任意の組合せを含む計算システムで実施されてもよい。任意の形式又は媒体のデジタルデータ通信（例えば、通信ネットワーク）を介してシステムの部品を相互に接続してもよい。通信ネットワークの例示は、ローカルエリアネットワーク（ＬＡＮ）と、広域ネットワーク（ＷＡＮ）と、インターネットとを含む。

コンピュータシステムは、クライアントとサーバとを含んでもよい。クライアントとサーバとは、一般的に互いに離れて、且つ通常に通信ネットワークを介してインタラクトする。相応するコンピュータで実行されるとともに、互いにクライアント-サーバの関係を有するコンピュータプログラムによって、クライアントとサーバとの関係を形成する。

本願の実施例は、プロセッサによって実行される際に、上記いずれかのビジネス監査報知方法を実現するコンピュータプログラムを記憶しているコンピュータ読取可能な媒体を提供した。

上記に示した様々な形式のフローを利用して、ステップを並び替え、追加又は削除することができると理解すべきである。例えば、本願に記載された各ステップは、並行に実行されてもよいし、順に実行されてもよいし、異なる順序で実行されてもよく、本願が開示した技術案が所望する結果を実現できる限り、本文はただし限定しない。

上述した具体的な実施形態は、本願の保護範囲に対する限定を構成しない。当業者は、設計要求や他の要因に応じて、さまざまな修正、組合、サブ組合及び置換を行うことができると理解すべきである。本願の趣旨及び原則の範囲内になされた任意の修正、等価な置換、改進などは、いずれも本願の保護範囲内に含まれるべきである。

本発明は、本願はコンピュータ技術分野に関し、具体的にクラウドコンピューティング及びクラウドプラットフォーム技術に関し、特にビジネス監査報知方法及びゲートウェイ、電子機器、読取可能な媒体及びコンピュータプログラムに関する。

ミニアプリは、ダウンロードや、インストールを必要とせずに使用可能なアプリケーションとして、ユーザの時間コスト及び携帯電話の内部メモリ容量を節約するとともに、開発者の開発コスト及び普及コストを大幅に低減することができる。

ミニアプリ開発者及び第三者の事業者は、例えばミニアプリパッケージ管理、基本情報設置、情報流れ・材料検索サービス、注文・支払いサービス、メッセージサービスなどのミニアプリの能力を豊富にするために、様々なアクセス使用方式を提供しており、プラットフォームインターフェースを介して操作することをサポートしてもよく、プラットフォームが提供したオープンアプリケーションプログラミングインターフェース（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ，ＡＰＩ）を呼び出すことで能力を使用してもよい。

第１の局面によれば、
ユーザ端末の操作要求に応答して監査プラットフォームにビジネス監査要求を送信することと、
前記監査プラットフォームにより返送された監査任務識別子に基づいて報知待ちメッセージを生成することと、
取得された監査結果及び前記報知待ちメッセージに基づいて、監査報知メッセージを生成することと、
前記監査報知メッセージを前記ユーザ端末にプッシュすることと、を含む、
ビジネス監査報知方法を提供した。

第２の局面によれば、
ゲートウェイがユーザ端末の操作要求に応答して送信したメッセージであるビジネス監査要求を受信することと、
監査結果を取得して記憶することで、前記ゲートウェイが、前記監査結果と、ゲートウェイが前記ビジネス監査要求に対して生成したメッセージである報知待ちメッセージとに基づいて、監査報知メッセージを生成することに供することと、を含む、
ビジネス監査報知方法を提供した。

第３の局面によれば、
ユーザ端末の操作要求に応答して、監査プラットフォームにビジネス監査要求を送信し、前記監査プラットフォームにより返送された監査任務識別子に基づいて、報知待ちメッセージを生成するように配置されている提出モジュールと、
取得された監査結果及び前記報知待ちメッセージに基づいて監査報知メッセージを生成し、前記監査報知メッセージを前記ユーザ端末にプッシュするように配置されているプッシュモジュールと、を含む、
ゲートウェイを提供した。

第４の局面によれば、
少なくとも１つのプロセッサと、
前記少なくとも１つのプロセッサと通信接続するメモリとを含む電子機器であって、
前記メモリに、前記少なくとも１つのプロセッサによって実行され得るコマンドが記憶されており、前記コマンドが前記少なくとも１つのプロセッサによって実行されることで、前記少なくとも１つのプロセッサがビジネス監査報知方法のいずれか一項に記載の方法を実行することができる、
電子機器を提供した。

第５の局面によれば、コンピュータに上述したいずれかのビジネス監査報知方法を実行させるためのコンピュータコマンドを記憶している非一時的なコンピュータ読取可能な記憶媒体を提供した。

第６の局面によれば、プロセッサによって実行されることで、上記分散記憶方法のいずれか一項に記載のビジネス監査報知方法を実現するコンピュータプログラムを提供した。

本願が提供したビジネス監査報知方法は、ユーザ端末により発された操作要求に応答して監査プラットフォームにビジネス監査要求を送信し、監査プラットフォームにより返送された監査任務識別子に基づいて、報知待ちメッセージを生成し、監査結果及び報知待ちメッセージに基づいて、監査報知メッセージを生成し、監査報知メッセージをユーザ端末にプッシュする。この方法は、汎用性があり、任意のタイプのビジネス監査（例えば、ミニアプリ能力の監査）をサポートするとともに、開発人員の人力コストを低減し、コード冗長性を低下させ、かつビジネスコードのメンテナンス性を向上することができる。

この部分で説明した内容は、本開示の実施例の肝心な又は重要な特徴を表記するためのものでもなく、本開示の範囲を限定するためのものでもないと理解すべきである。本開示の他の特徴は、以下の明細書によって理解し易くなるであろう。

図面は、本技術案がよりよく理解されるためのものであり、本願に対する限定を構成しない。
本願の実施例が提供したビジネス監査報知方法の適用場面模式図である。 本願の実施例が提供したビジネス監査報知方法のフローチャートである。 本願の実施例が提供したユーザの操作要求に応答して監査プラットフォームにビジネス監査要求を送信するフローチャートである。 本願の実施例が提供した監査報知メッセージをユーザ端末にプッシュするフローチャートである。 本願の実施例が提供したビジネス監査報知方法のフローチャートである。 本願の実施例が提供したゲートウェイの原理ブロック図である。 本願の実施例が提供した提出モジュールの原理ブロック図である。 本願の実施例が提供した認証手段の原理ブロック図である。 本願の実施例が提供したプッシュモジュールの原理ブロック図である。 本願の実施例が提供した別のプッシュモジュールの原理ブロック図である。 本願の実施例が提供した監査プラットフォームの原理ブロック図である。 本実施例が提供したビジネス監査報知方法のフローチャートである。 本願の実施例のビジネス監査報知方法を実現するための電子機器のブロック図である。

以下、図面に合わせて本願の例示的な実施例について説明する。その中、理解に役立つように本願の実施例の各詳細を含み、これらはあくまで例示的なものであると理解すべきである。そのため、当業者は、本願の範囲及び趣旨から逸脱せずに、ただし説明した実施例に対して、様々な変更や、修正をなし得ることを認識すべきである。同様に、明確及び簡明のために、以下の説明において公知の機能及び構成に対する説明を省略している。

衝突しない場合、本願の各実施例及び実施例における各特徴は互いに組み合わせることができる。

本明細書で使用されるような「及び/又は」という用語は、一つ又は複数の関連列挙アイテムの任意及び全ての組み合わせを含む。

本明細書で使用される用語は、特定の実施例を説明するためのものに過ぎず、本願を限定することを意図しない。文脈から別途明らかに指摘しない限り、本明細書で使用されるような「一つ」及び「この」という単数形は、複数形も含むことを意図する。さらに理解すべきことは、本明細書において「含む」及び/又は「・・・で製作される」という用語を使用する場合、前記特徴、全体、ステップ、操作、素子及び/又はアセンブリが存在することを指定するが、一つ又は複数の他の特徴、全体、ステップ、操作、素子、アセンブリ及び/又はそのグループが存在すること、又は追加することを除外しない。

本願の実施例が指すミニアプリとは、ダウンロードや、インストールを必要とせずにリアルタイム通信アプリケーション上で実行され得るアプリケーションプログラムであり、一般的に第三者のアプリケーションにロードされる。ミニアプリに対する修正又は操作行為は、監査プラットフォームの人工監査を経る必要があることが多いため、ミニアプリ開発者又は第三者の事業者は、オープンＡＰＩゲートウェイを呼び出す時に監査結果を即時に取得することができず、非同期報知メカニズムにより監査結果を報知する必要がある。

しかしながら、現在のオープンＡＰＩゲートウェイは、非同期報知メカニズムをサポートできないため、ミニアプリ能力の開発過程において、監査に係る操作場面ごとに、非同期報知機能をカスタマイズして開発する必要があり、これは開発人力をかかるだけでなく、コード冗長をもたらし、全体のサービス端のアーキテクチャのメンテナンス性を影響した。そして、異なる開発者が開発した非同期報知コードは、報知メッセージが必ず到着することを保証する統一のメカニズムがないため、報知メッセージのプッシュ漏れの状況が存在する可能性があり、ミニアプリ開発者又は第三者の事業者によるミニアプリ能力の使用を影響した。

オープンＡＰＩゲートウェイに存在する上記問題に対して、本願はビジネス監査報知方法を提供して、ＡＰＩゲートウェイの呼び出し及び非同期報知の機能閉ループを実現し、開発者の人力コストを低減し、コード冗長性を低下させ、ビジネスコードのメンテナンス性を向上させるために用いられる。

例示的に、図１は本願の実施例が提供したビジネス監査報知方法の適用場面模式図である。図１に示すように、この適用場面は、少なくとも一つのユーザ端末１１、ゲートウェイ１２及び監査プラットフォーム１３を含んでもよく、ユーザ端末１１、ゲートウェイ１２及び監査プラットフォーム１３は、ネットワークを介して通信する。ただし、ユーザ端末１１は、ミニアプリ開発者又は第三者の事業者が使用する端末であってもよい。ミニアプリ開発者及び第三者の事業者は、ユーザ端末１１で一つ又は複数のミニアプリを開発してもよく、既に存在しているミニアプリを修正してもよい。

一部の実施例において、ミニアプリ開発者及び第三者の事業者は、ミニアプリ開発プラットフォームを介してミニアプリ能力を修正することができる。ミニアプリ開発プラットフォームは、ミニアプリを搭載するアプリケーションプログラム（Ａｐｐｌｉｃａｔｉｏｎ，ＡＰＰ）運営者が独立して運営するプラットフォームであってもよく、ミニアプリを搭載するＡＰＰの運営者と連携関係を有する第三者のミニアプリ開発プラットフォームであってもよい。選択的に、このミニアプリ開発プラットフォームは、ミニアプリ開発者ツールとも呼ばれ、ミニアプリを生産し、修正するためのツールである。ミニアプリ開発プラットフォームの具体的な体現形式について、本願はそれを限定しない。

ゲートウェイ１２は、例えば、ミニアプリパッケージのリリース、ミニアプリ名称の修正などの、ユーザ端末１１により提出されたミニアプリ能力に対する操作要求を受信し、操作要求に基づいて監査プラットフォームにビジネス監査要求を送信して、ミニアプリの操作要求が関連規定に合致するか否かを監査し、同時に報知待ちメッセージを生成することで、監査結果を取得した後に監査報知メッセージを生成する。

監査プラットフォーム１３は、ビジネス監査要求の具体的な内容に応じて、ミニアプリ能力が正当であるか否かを監査し、監査結果をメッセージキューに記憶する。実際の応用において、この監査プラットフォーム１３は、クラウドサーバであってもよい。本願の実施例は、監査プラットフォームの具体的な形式を限定せず、それは実際のニーズに応じて確定することができ、ただしは説明を繰り返さない。

ゲートウェイ１１は、メッセージキューから監査結果を取得し、監査結果と報知待ちメッセージとを組み合わせて監査報知メッセージを取得し、さらに、監査報知メッセージをユーザ端末に送信し、ユーザはユーザ端末から監査結果を知ることができる。

以降、具体的な実施例によって本願の技術案を詳細に説明する。説明しておくことは、以下の幾つかの具体的な実施例は、互いに組み合わせてもよく、同じ又は類似な概念又は過程について、幾つかの実施例において説明を繰り返さない可能性がある。

第１の態様において、本願の実施例は、ゲートウェイに用いられるビジネス監査報知方法を提供し、このゲートウェイは、ＡＰＩゲートウェイであってもよく、信号を伝送するために用いられる他のゲートウェイであってもよい。

図２は、本願の実施例が提供したビジネス監査報知方法のフローチャートである。図２を参照して、本願の実施例が提供したビジネス監査報知方法は、
ユーザ端末により発された操作要求に応答して、監査プラットフォームにビジネス監査要求を送信するステップ２０１を含む。

ただし、ユーザは、使用しているユーザ端末により操作要求を発する。操作要求は、ミニアプリビジネスに対する要求であってもよく、他のアプリケーションプログラムに対する要求であってもよい。

一部の実施例において、操作要求は、ミニアプリの基本情報（例えば、名称、アバター、プロファイル、業界カテゴリなど）の修正、ミニアプリパッケージのリリース、配信材料の提出（検索・推奨ｆｅｅｄ）及び支払いサービスの開通などを含むが、これらに限られない。

説明の便利上、本願の実施例は、ユーザがユーザ端末により操作要求を発すことを、ユーザ端末が操作要求を発すこととして表現する。ただし、ユーザ端末は、携帯電話、携帯情報端末、パーソナルコンピュータ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ，ＰＣ）、複合機などの、通信機能を有する端末であってよい。

一部の実施例において、ユーザは、ミニアプリ開発者であってもよく、第３者の事業者であってもよい。ただし、ミニアプリ開発者は、ミニアプリの所有者又は管理者である。第３者の事業者は、ミニアプリ開発者が承認した第３者の事業者、又は管理者が承認した第３者の事業者である。ミニアプリ開発者又は管理者は、第３者の事業者に対してすべての使用権限を承認してもよく、一部の使用権限のみを承認してもよい。第３者の事業者は、ミニアプリ開発者又は管理者の承認権限内でミニアプリ能力を管理する。

一部の実施例において、ミニアプリ開発者又は管理者は、ミニアプリ能力を開発し、修正する開発過程において、監査プラットフォームがミニアプリ能力の正当性を監査するように、監査プラットフォームに監査を要求する必要がある。

一部の実施例において、ミニアプリプラットフォームは、例えば、ミニアプリパッケージ管理、基本情報設置、情報流れ・材料検索サービス、注文・支払いサービス、メッセージサービスなどのミニアプリ能力を豊富にするために、様々なアクセス使用方式を提供しており、ミニアプリプラットフォームインターフェースを介して操作してもよく、ミニアプリプラットフォームが提供したオープンＡＰＩを呼び出すことで能力を使用してもよい。

一部の実施例において、ユーザはゲートウェイに操作要求を発し、ただし、操作要求はミニアプリの基本情報（例えば、名称、アバター、プロファイル、業界カテゴリなど）の修正、ミニアプリパッケージのリリース、配信材料の提出（検索・推奨ｆｅｅｄ）及び支払いサービスの開通などを含むが、これらに限られない。操作要求には、ユーザ身元識別子及びアプリケーションプログラム識別子が付けられている。本実施例において、アプリケーションプログラム識別子は、任意の形式のミニアプリ識別子であってよい。

ただし、ユーザ身元識別子はユーザ身元を識別するための識別子であり、ミニアプリ識別子はミニアプリ身元を識別するための識別子である。操作タイプは、ミニアプリパッケージ、基本情報設置、情報流れ・材料検索サービス、注文・支払いサービス及びメッセージサービスを含むが、これらに限られない。操作パラメータは、操作タイプに関連しており、それぞれの操作タイプが異なるパラメータに対応する。例えば、ミニアプリパッケージをリリースする場合、ミニアプリパッケージ識別子（ｐａｃｋａｇｅ_ｉｄ）及びミニアプリパッケージバージョン（ｐａｃｋａｇｅ_ｖｅｒｓｉｏｎ）パラメータを提供する必要があり、ミニアプリ名称を修正する場合、ミニアプリ名称（ａｐｐ_ｎａｍｅ）パラメータを提供する必要がある。

一部の実施例において、ゲートウェイは、ユーザ端末により発された操作要求を受信した後に、監査プラットフォームにビジネス監査要求を送信する。監査プラットフォームは、人工、又は、機器と人工とを組合せる監査方式によって、ミニアプリを監査することができる。

ただし、監査要求と操作要求とは対応している。一部の実施例において、監査要求のタイプは、ミニアプリパッケージ監査、名称監査、業界カテゴリ監査、アバター及びプロファイル監査、（推奨・検索）材料監査、支払いアカウント監査などを含むが、これらに限られない。

ステップ２０２において、監査プラットフォームが返送した監査任務識別子に基づいて報知待ちメッセージを生成する。

ただし、監査任務識別子は、監査プラットフォームがビジネス監査要求に対して割り当てる識別子である。

一部の実施例において、監査プラットフォームは、ゲートウェイのビジネス監査要求を受信した後、ゲートウェイに監査任務識別子を返送する。ゲートウェイは、監査任務識別子を受信した後、報知待ちメッセージを生成する。

一部の実施例において、報知待ちメッセージが報知待ちメッセージライブラリに記憶されており、報知待ちメッセージに係るフィールドは、監査任務識別子、ユーザ身元識別子、ビジネス監査提出時間、監査報知テンプレート、操作パラメータ及び監査結果メッセージ項目を含む。

ただし、監査報知テンプレートは、事前に配置されてもよく、操作タイプごとに監査報知テンプレートが個別に配置される。それぞれの監査報知テンプレートは、監査通過サブテンプレート及び監査拒絶サブテンプレートを含んでもよい。

一部の実施例において、監査報知テンプレートは、ｊｓｏｎ構成を採用してもよく、例えば、ミニアプリパッケージの監査拒絶サブテンプレートは、以下のフォーマットを採用してもよい。

ただし、${…}のような形の文字列は、書き込み対象フィールドを表す。書き込み対象フィールドは、提出された要求パラメータ及び監査結果メッセージから、対応するフィールド値を抽出して書き込むことができる。例えば、ａｐｐ_ｉｄは、ミニアプリ識別子ＩＤを表し、ｄｅｖｅｌｏｐｅｒ_ｉｄ及びｔｐ_ｄｅｖｅｌｏｐｅｒ_ｉｄは、それぞれ開発者識別子ＩＤ及び第３者の事業者識別子ＩＤを表し、ｒｅａｓｏｎフィールドは、監査失敗原因を表し、ｐａｃｋａｇｅ_ｉｄ及びｐａｃｋａｇｅ_ｖｅｒｓｉｏｎは、それぞれミニアプリパッケージ識別子ＩＤ及びミニアプリパッケージバージョンを表す。

ステップ２０３において、取得された監査結果及び報知待ちメッセージに基づいて監査報知メッセージを生成する。

ただし、監査結果は、監査通過及び監査拒絶を含む。例えば、監査プラットフォームは、ミニアプリ能力が設定された要求に合致すると認定した場合、監査結果が監査通過になる。監査プラットフォームは、ミニアプリ能力が設定された要求に合致しないと認定した場合、監査結果は監査拒絶になる。

一部の実施例において、監査プラットフォームは監査員により監査プラットフォームのページ上で人工監査を行う。監査員はミニアプリ能力が設定された要求を満たすと認定した場合、監査結果が監査通過になる。監査員はミニアプリ能力が設定された要求を満たさないと認定した場合、監査結果が監査拒絶になる。

一部の実施例において、ゲートウェイは、監査結果と報知待ちメッセージとを組み合わせて、監査報知メッセージを生成する。例えば、ゲートウェイは、監査結果を取得した後、監査結果を報知待ちメッセージの対応するフィールドに加えて、監査報知メッセージを取得する。

例えば、監査報知メッセージは、以下のようなフォーマットを採用することができる。

ただし、ミニアプリの識別子は「１４５２３６５」であり、開発者識別子は「１７３２８２３２」であり、監査提出時間は「２０１９-０１-１４ １２:４５:１０」であり、監査のタイプは「ＰＡＣＫＡＧＥ_ＡＵＤＩＴ_ＦＡＩＬ」であり、監査失敗の原因は「名称と実際に開いた後の名称とが一致していない」であり、ミニアプリパッケージの識別子は「７４５８１５」であり、ミニアプリパッケージのバージョンは「１.３.４６」である。

ステップ２０４において、監査報知メッセージをユーザ端末にプッシュする。

ゲートウェイは、監査報知メッセージを生成した後、監査報知メッセージをユーザ端末にプッシュして、ユーザがユーザ端末により監査結果を見る。

一部の実施例において、図３に示すように、ユーザの操作要求に応答して監査プラットフォームにビジネス監査要求を送信することは、操作要求を解析してユーザ身元識別子及びミニアプリ識別子を取得するステップ３０１を含む。

一部の実施例において、ゲートウェイは、操作要求を受信した後、操作要求を解析して、ユーザ身元、ミニアプリ識別子、操作タイプ及び操作パラメータを取得する。

ただし、操作タイプは、ミニアプリパッケージ管理、基本情報設置、情報流れ・材料検索サービス、注文・支払いサービス及びメッセージサービスを含むが、これらに限られない。操作パラメータは、操作タイプに関連しており、それぞれの操作タイプが異なるパラメータに対応する。

例えば、ユーザ端末が発した操作要求は、ミニアプリ名称を修正する要求であれば、操作要求にユーザ身元識別子、ミニアプリ識別子、操作タイプ（名称修正）及び名称パラメータ（ミニアプリの新しい名称）が含まれる。

一部の実施例において、操作パラメータは、第３者の事業者に対する承認時間を標記するためのタイムスタンプをさらに含み、即ち、第３者の事業者は承認時間内でミニアプリを開発、修正することができる。

ステップ３０２において、ユーザ身元識別子及びミニアプリ識別子に基づいてユーザ身元を検証する。

一部の実施例において、ユーザ身元識別子及びミニアプリ識別子に基づいてユーザ身元を認証する。例えば、ゲートウェイは、ユーザ身元識別子に基づいてミニアプリ識別子との権限関係を検証する。このユーザがこのミニアプリ識別子に対応するミニアプリに対する操作権限を持っていない場合、直接にユーザ端末に無権限メッセージを返送する。このユーザがこのミニアプリ識別子に対応するミニアプリに対する操作権限を持っている場合、後続操作を行う。

ステップ３０３において、ユーザ身元に対する検証が成功した場合、監査プラットフォームにビジネス監査要求を送信する。

ユーザ身元に対する検証が成功した場合、ゲートウェイは、監査プラットフォームにビジネス監査要求を送信する。ビジネス監査要求には、ミニアプリ識別子、操作タイプ（名称修正）及び名称パラメータ（ミニアプリの新しい名称）が含まれる。

一部の実施例において、監査プラットフォームは、ビジネス監査要求を受信した後、ゲートウェイに監査任務識別子ＩＤを返送し、ゲートウェイが監査任務識別子を受信した後、報知テンプレートライブラリから操作タイプに対応する監査報知テンプレートを取得し、監査報知テンプレート、監査任務識別子に基づいて、報知待ちメッセージを生成し、報知待ちメッセージを報知待ちメッセージライブラリに記憶する。ただし、報知待ちメッセージは、監査任務識別子、ユーザ身元識別子、ビジネス監査提出時間、監査報知テンプレート、操作パラメータ及び監査結果メッセージ項目を含む。

一部の実施例において、監査報知テンプレートは、報知テンプレートライブラリに予め設置され、記憶されているテンプレートである。ただし、それぞれの操作タイプは、１つの監査報知テンプレートに対応する。監査報知テンプレートは、操作タイプに応じて特定されたテンプレートであり、汎用性がある。監査報知テンプレートを報知テンプレートライブラリに記憶して、必要な時に監査報知テンプレートを随時に抽出することで、報知待ちメッセージの生成の効率を向上することでき、そして、エラーの確率を低減することができる。

ゲートウェイは、操作要求を受信した後、操作要求のタイプに基づいて、監査報知テンプレートライブラリを照会して、それと整合する監査報知テンプレートを取得し、さらに監査任務識別子、ユーザ身元識別子、ビジネス監査提出時間、監査報知テンプレート、操作パラメータ及び監査結果メッセージ項目に基づいて、報知待ちメッセージを生成する。

一部の実施例において、監査プラットフォームは、ビジネス監査要求における監査待ち内容を監査した後、監査結果をメッセージキューに送信する。ただし、メッセージキューは、監査結果を記憶するための行列であり、メッセージキューにおける各メッセージは、いずれも監査任務識別子及び監査結果を含む。

一部の実施例において、同一監査結果は、１回でマルチプッシュされることがあり得る。例えば、ミニアプリ開発者と第３者の事業者との両方は、監査結果を取得する必要がある場合、この監査結果がミニアプリの開発者に送信されるだけではなく、第３者の事業者に送信されてもよい。メッセージキューを利用してゲートウェイと監査プラットフォームとを隔離し、１回の監査結果を多方向にプッシュして消費する目的を実現することができる。

一部の実施例において、ゲートウェイは、メッセージキューから監査結果を申し込んで、監査結果及び報知待ちメッセージを組み合わせて監査報知メッセージを取得する。

例えば、ゲートウェイは、監査任務識別子に従ってメッセージキューから監査結果を取得し、報知待ちメッセージライブラリから報知待ちメッセージを取得し、監査結果を報知待ちメッセージにおける監査結果メッセージ項目に組み込むことで、監査報知メッセージを取得する。

実際の応用において、監査報知メッセージを失った状況が現れると、ユーザ端末に監査報知メッセージを再度プッシュする必要がある。監査結果をメッセージキューに記憶することで、ゲートウェイは、メッセージキューから監査結果を複数回申し込んで、ユーザ端末に監査報知メッセージを複数回プッシュすることを実現し、プッシュ漏れの問題を効果的に回避することができる。

一部の実施例において、ユーザ端末は、ネットワーク故障などの原因で監査報知メッセージを受信できないことがあるため、ゲートウェイは、所定の時間間隔、所定のプッシュ回数に従ってユーザ端末に監査報知メッセージを複数回プッシュすることができる。例えば、所定の最大プッシュ回数は５回であり、所定の時間間隔は１分、５分、１５分、１時間又は６時間である。ゲートウェイは、ユーザ端末に監査報知メッセージを初回にプッシュした後、１分の間隔で第１回の補足プッシュを行い、第１回の補足プッシュを完了した後、５分の間隔で第２回の補足プッシュを行い、第２回の補足プッシュを完了した後、１５分の間隔で第３回の補足プッシュを行い、第３回の補足プッシュを完了した後、１時間の間隔で第４回の補足プッシュを行い、第４回の補足プッシュを完了した後、６時間の間隔で第５回の補足プッシュを行う。プッシュ回数及びプッシュ時間間隔を設定することで、プッシュの成功率を向上することができる。

一部の実施例において、図４に示すように、監査報知メッセージをユーザ端末にプッシュすることは、
プッシュアドレスライブラリからユーザ端末のプッシュアドレスを取得するステップ４０１を含む。

ただし、プッシュアドレスライブラリは、プッシュアドレスを記憶するデータベースである。ユーザ端末のアドレスは、プッシュアドレスライブラリ内に記憶されていることで、ゲートウェイがプッシュアドレスに従ってユーザ端末に監査報知メッセージをプッシュしやすくなる。

一部の実施例において、ユーザは、ユーザ端末により自分のアドレスをプッシュアドレスライブラリに予め記憶して、ゲートウェイにより必要な時にプッシュアドレスライブラリから呼び出されることに供する。

ステップ４０２において、プッシュアドレスに従って監査報知メッセージをユーザ端末にプッシュする。

ゲートウェイは、監査任務識別子に従ってメッセージキューから対応する監査結果を申し込み、監査任務識別子に従って報知待ちメッセージライブラリから対応する報知待ちメッセージを取得し、この監査任務識別子に対応する監査結果及び報知待ちメッセージを組み合わせて、監査報知メッセージを取得する。ゲートウェイは、プッシュアドレスライブラリからユーザ端末のプッシュアドレスを取得し、プッシュアドレスに従って監査報知メッセージをユーザ端末に送信する。

一部の実施例において、ゲートウェイは、プッシュアドレスに従ってユーザ端末に監査報知メッセージを複数回プッシュして、プッシュの成功率を向上することができる。

一部の実施例において、報知待ちメッセージライブラリにおける報知待ちメッセージが長い時間にわたって監査結果の記録がない場合、ゲートウェイは、直接に監査プラットフォームを照会して、監査結果を取得し、監査結果と報知待ちメッセージとを組み合わせてからユーザ端末にプッシュし、それによりメッセージのプッシュ漏れを回避する。

本実施例が提供したビジネス監査報知方法は、ユーザ端末が発した操作要求に応答して監査プラットフォームにビジネス監査要求を送信し、監査プラットフォームが返送した監査任務識別子に基づいて報知待ちメッセージを生成し、監査結果を取得して、監査結果及び報知待ちメッセージに基づいて監査報知メッセージを生成し、監査報知メッセージをユーザ端末にプッシュする。この方法は、任意のミニアプリ能力の非同期報知メカニズムをサポートできるとともに、開発者の人力コストを低減し、コード冗長性を低下させ、かつビジネスコードのメンテナンス性を向上した。

第２の態様において、本願の実施例は、ビジネス監査報知方法を提供し、この方法が監査プラットフォームに適用される。

図５は、本願の実施例が提供したビジネス監査報知方法のフローチャートである。図５を参照して、本願の実施例は、ビジネス監査報知方法を提供し、
ビジネス監査要求を受信するステップ５０１を含む。

ただし、ビジネス監査要求は、ゲートウェイがユーザ端末により発された操作要求に応答して送信した要求である。

一部の実施例において、ゲートウェイは、ユーザ端末より発された操作要求を受信した後、監査プラットフォームにビジネス監査要求を発す。ただし、操作要求は、ミニアプリの基本情報（例えば、名称、アバター、プロファイル、業界カテゴリなど）の修正、ミニアプリパッケージのリリース、配信材料提出（検索・推奨ｆｅｅｄ）及び支払いサービス開通などを含むが、これらに限られない。ビジネス監査要求は操作要求に基づき、即ち、ビジネス監査要求は操作要求に対応しており、ビジネス監査要求のタイプはミニアプリパッケージ監査、名称監査、業界カテゴリ監査、アバター及びプロファイル監査、（ｆｅｅｄ・検索）材料監査及び支払いアカウント監査などを含む。

ステップ５０２において、監査結果を取得して記憶して、ゲートウェイが監査結果及び報知待ちメッセージに基づいて監査報知メッセージを生成するために供する。

ただし、報知待ちメッセージは、ゲートウェイがビジネス監査要求に対して生成したメッセージである。

一部の実施例において、監査プラットフォームは、監査人員によって監査するため、監査プラットフォームがビジネス監査要求を受信した後、表示装置によって監査人員にビジネス監査要求を表示することができる。監査人員は、ビジネス監査要求における監査タイプを監査して、関連規定に合致する監査タイプに対して監査通過を下し、関連規定に合致しない監査タイプに対して監査拒絶を下す。

一部の実施例において、監査プラットフォームは、監査人員の監査結果を取得した後、監査結果をメッセージキューに送信して、ゲートウェイが必要な時に監査結果を取得し、又はメッセージキューが主動的に監査結果をゲートウェイにプッシュすることに供する。

一部の実施例において、監査プラットフォームは、ビジネス監査要求を受信した後、ゲートウェイに監査任務識別子を返送し、ただし、監査任務識別子は監査任務の唯一の識別子であり、後続のステップにおいて、ゲートウェイが監査任務識別子で報知待ちメッセージ及び監査結果を取得する。

例えば、ゲートウェイは、監査任務識別子に従ってメッセージキューから対応する監査結果を申し込み、監査任務識別子に従って報知待ちメッセージライブラリから対応する報知待ちメッセージを取得し、監査結果と報知待ちメッセージとを組み合わせて、監査報知メッセージを取得する。

本実施例が提供したビジネス監査報知方法は、ビジネス監査要求を受信し、監査結果を受信し、監査結果を記憶して、ゲートウェイが監査結果及び報知待ちメッセージに基づいて監査報知メッセージを生成することに供し、監査報知メッセージをユーザ端末にプッシュする。この方法は、任意のビジネス監査の非同期報知メカニズムをサポートできるとともに、開発人員の人力コストを低減し、コード冗長性を低下させ、ビジネスコードのメンテナンス性を向上した。

第３の態様において、本願の実施例は、ゲートウェイを提供した。図６は、本願の実施例が提供したゲートウェイの原理ブロック図である。

図６を参照して、本願の実施例が提供したゲートウェイは、
ユーザ端末の操作要求に応答して監査プラットフォームにビジネス監査要求を送信し、監査プラットフォームにより返送された監査任務識別子に基づいて報知待ちメッセージを生成するように配置されている提出モジュール６０１と、
取得された監査結果及び報知待ちメッセージに基づいて監査報知メッセージを生成し、監査報知メッセージをユーザ端末にプッシュするように配置されているプッシュモジュール６０２とを含む。

一部の実施例において、監査結果がメッセージキューから取得される。監査プラットフォームは、監査結果を取得した後、監査結果をメッセージキューに格納して、メッセージキューが監査結果を受信した後、監査結果をプッシュモジュール６０２に伝送する。或いは、プッシュ手段６０２は、所定の条件に従って主動的にメッセージキューから監査結果を抽出してもよい。例えば、抽出の時間を毎日８:００～１８:００に予め設置して、抽出の時間間隔が３０分であり、プッシュ手段６０２は、この所定時間及び時間間隔に従って監査結果を抽出する。

一部の実施例において、図７に示すように、提出モジュール７００は、
監査プラットフォームにビジネス監査要求を送信するように配置されている監査提出手段７０１を含む。

一部の実施例において、監査提出手段７０１は、ユーザ端末により発された操作要求に基づいて監査プラットフォームにビジネス監査要求を送信する。

ただし、ユーザ端末は、ミニアプリ開発者又は第３者の事業者が使用するミニアプリを開発する端末である。ユーザは、例えば、ミニアプリパッケージ管理、基本情報設置、情報流れ・材料検索サービス、注文・支払いサービス、メッセージサービスなどのミニアプリ能力を豊富にするために、ミニアプリを開発し、或いは修正する。すべての開発及び修正は、監査プラットフォームを介して監査される必要がある。

ただし、操作要求は、ミニアプリの基本情報（例えば、名称、アバター、プロファイル、業界カテゴリなど）の修正、ミニアプリパッケージのリリース、配信材料の提出（検索・推奨ｆｅｅｄ）及び支払いサービスの開通などを含むが、これらに限られない。

ただし、ビジネス監査要求は、操作要求に対するものであり、操作要求に応じて、異なる操作要求は、異なるビジネス監査要求に対応している。ビジネス監査要求は、ミニアプリパッケージ監査、名称監査、業界カテゴリ監査、アバター及びプロファイル監査、（推奨・検索）材料監査、支払いアカウント監査などを含むが、これらに限られない。

第１の生成手段７０２は、監査プラットフォームにより返送された監査任務識別子に基づいて報知待ちメッセージを生成するように配置されている。

一部の実施例において、監査プラットフォームは、ゲートウェイのビジネス監査要求を受信した後、ゲートウェイに監査任務識別子を返送する。ただし、監査任務識別子は、監査プラットフォームがビジネス監査要求のために割り当てる識別子である。ゲートウェイが監査任務識別子を受信した後、第１の生成手段７０２が報知待ちメッセージを生成する。

一部の実施例において、第１の生成手段７０２は、操作要求のタイプに基づいて監査報知テンプレートを取得し、ユーザ身元識別子、監査任務識別子、ビジネス監査提出時間、監査報知テンプレート、操作パラメータ及び監査結果メッセージ項目に基づいて、報知待ちメッセージを生成する。

ただし、ユーザ身元識別子は、ユーザ身元を示す唯一の識別子である。ビジネス監査提出時間は、監査提出手段が監査プラットフォームに監査任務を提出する時間である。監査報知テンプレートは、事前に配置されてもよく、各種の操作タイプは、報知テンプレートを個別に配置する。各種の報知テンプレートは、監査通過サブテンプレート及び監査拒絶サブテンプレートを含んでもよい。操作パラメータは、操作要求における要求内容であり、操作タイプによって操作パラメータが異なる。例えば、ミニアプリパッケージをリリースする場合、ミニアプリパッケージ識別子（ｐａｃｋａｇｅ_ｉｄ）及びミニアプリパッケージバージョン（ｐａｃｋａｇｅ_ｖｅｒｓｉｏｎ）パラメータを提供する必要があり、ミニアプリ名称を修正する場合、ミニアプリ名称（ａｐｐ_ｎａｍｅ）パラメータを提供する必要がある。監査結果メッセージ項目は、監査結果を書き込むための項目である。第１の生成手段７０２により生成された報知待ちメッセージのうち、監査結果メッセージ項目は空きである。

一部の実施例において、提出モジュール６０１は、ユーザ端末の身元を認証するように配置されている認証手段をさらに含む。

図８に示すように、認証手段８００は、
操作要求を解析して、ユーザ身元識別子及びミニアプリ識別子を取得するように配置されている解析サブ手段８０１を含む。

一部の実施例において、操作要求には、ユーザ身元識別子及びミニアプリ識別子が含まれており、解析サブ手段８０１は、操作要求を解析することで、ユーザ身元識別子及びミニアプリ識別子を取得することができる。

検証サブ手段８０２は、ユーザ身元識別子及びミニアプリ識別子に基づいて、ユーザ身元を検証するように配置されている。

一部の実施例において、検証サブ手段８０２は、ユーザ身元識別子に基づいてミニアプリ識別子との権限関係を検証する。このユーザがこのミニアプリ識別子に対応するミニアプリに対する操作権限を持っていない場合、ユーザ端末に無権限メッセージを直接返送し、このユーザがこのミニアプリ識別子に対応するミニアプリに対する操作権限を持っている場合、後続の操作を行う。

図９に示すように、プッシュモジュール９００は、
取得された監査結果及び報知待ちメッセージに基づいて、監査報知メッセージを生成するように配置されている第２の生成手段９０１を含む。

ただし、監査結果は、監査通過及び監査拒絶を含む。監査標準に合致する場合、監査プラットフォームは監査通過の監査結果を得て、監査標準に合致しない場合、監査プラットフォームは監査拒絶の監査結果を得る。

一部の実施例において、第２の生成手段９０１は、監査結果を取得した後、監査結果を報知待ちメッセージにおける監査報知メッセージ項目に書き込み、監査報知メッセージを生成する。

プッシュ手段９０２は、監査報知メッセージをユーザ端末にプッシュするように配置されている。

一部の実施例において、プッシュ手段９０２は、プッシュアドレスライブラリから開発者又は第３者の事業者のアドレスを取得し、監査報知メッセージを開発者又は第３者の事業者にプッシュする。

一部の実施例において、図１０に示すように、プッシュモジュール１０００は、第２の生成手段１００１、プッシュ手段１００２及び申し込み手段１００３を含み、ただし、第２の生成手段１００１及びプッシュ手段１００２の原理及び機能は、第２の生成手段９０１及びプッシュ手段９０２と同様であり、ただし説明を繰り返さない。

申し込み手段１００３は、メッセージキューから監査結果を申し込み、監査結果を第２の生成手段に伝送するように配置されている。

説明しておくことは、メッセージキューが監査結果を記憶するための行列である。メッセージキューは、監査プラットフォームに設置されてもよく、ゲートウェイに設置されてもよく、監査プラットフォーム及びゲートウェイから独立して設置されてもよい。メッセージキューを利用して監査プラットフォームとゲートウェイとをデカップリングすることで、１回のプッシュで複数の箇所で消費される目的を実現する。

一部の実施例において、ゲートウェイは、監査報知テンプレートを記憶するように配置されている報知テンプレートライブラリ１００４をさらに含む。監査報知テンプレートは、報知テンプレートライブラリ１００４に予め配置されて記憶されていてもよい。監査報知テンプレートは、操作要求のタイプと整合し、そして、それぞれの操作タイプは、２つの監査報知テンプレート、即ち、監査通過テンプレート及び監査拒絶テンプレートに対応する。監査通過テンプレート及び監査拒絶テンプレートの設置形式は、本願の方法部分で言及されており、ただし説明を繰り返さない。

説明しておくことは、報知テンプレートライブラリ１００４は、ゲートウェイに設置されてもよく、ゲートウェイから独立した他の手段又はモジュールに設置されてもよく、報知テンプレートを記憶でき、かつ提出モジュール及びプッシュモジュールがこの報知テンプレートライブラリにアクセスできるようにすればよい。

プッシュアドレスライブラリ１００５は、ユーザ端末のプッシュアドレスを記憶するように配置されている。ただし、プッシュアドレスは、ユーザにより予め配置される報知を受信するアドレスである。

一部の実施例において、ミニアプリ開発者及び第３者の事業者は、それぞれのアドレスをプッシュアドレスライブラリに予め設置してもよく、それにより、プッシュモジュールが必要な場合に、ミニアプリ開発者又は第３者の事業者のアドレスを取得しやすくなる。

説明しておくことは、プッシュアドレスライブラリ１００５は、ゲートウェイに設置されてもよく、ゲートウェイから独立した他の手段又はモジュールに設置されてもよく、アドレスを記憶でき、かつ提出モジュール及びプッシュモジュールがこのプッシュアドレスライブラリにアクセスできるようにすればよい。

本実施例が提供したゲートウェイは、提出モジュールを利用して、ユーザ端末の操作要求を受信した場合、監査プラットフォームにビジネス監査要求を送信し、監査プラットフォームより返送された監査任務識別子に基づいて、報知待ちメッセージを生成し、プッシュモジュールにより取得された監査結果及び報知待ちメッセージを利用して、監査報知メッセージを生成し、監査報知メッセージをユーザ端末にプッシュする。このゲートウェイは、汎用性があり、任意タイプのビジネス監査（例えば、ミニアプリ能力の監査）をサポートできるとともに、開発人員の人力コストを低減し、コード冗長性を低下させ、かつビジネスコードのメンテナンス性を向上した。

第４の態様において、本願の実施例は、監査プラットフォームを提供し、この監査プラットフォームは、アプリケーションプログラムのビジネス、例えば、ミニアプリのビジネスを監査することができる。

図１１は、本願の実施例が提供した監査プラットフォームの原理ブロック図である。図１１に示すように、監査プラットフォーム１１００は、
ビジネス監査要求を受信するように配置されている受信モジュール１１０１を含む。

ただし、ビジネス監査要求は、ゲートウェイがユーザ端末の操作要求に応答して送信したメッセージである。

取得モジュール１１０２は、監査結果を取得するように配置されている。

一部の実施例において、監査プラットフォームは、監査人員によって人工監査を行う。監査結果は、監査人員が監査要求を監査した結果である。例えば、監査プラットフォームは、監査人員に監査要求、即ち、監査要求における監査事項を表示し、監査人員は、監査事項を監査し、監査結果を得て、この監査結果を監査プラットフォームに伝送する。

一部の実施例において、監査プラットフォームは、他の態様によって監査してもよく、例えば、人工と機器とを結合する態様によって監査してもよい。

記憶モジュール１１０３は、監査結果を記憶するように配置されている。

一部の実施例において、記憶モジュール１１０３は、メッセージキューの形で監査結果を記憶する。記憶モジュール１１０３は、監査プラットフォームに設置されてもよく、監査プラットフォームから独立した他のモジュール又は手段に設置されてもよい。

一部の実施例において、監査プラットフォームは、さらに、
ゲートウェイに監査任務識別子を返送するように配置されている任務識別子生成モジュールを含む。ただし、監査任務識別子は、監査任務の唯一の識別子である。

本願の実施例が提供した監査プラットフォームは、受信モジュールを利用してビジネス監査要求を受信し、取得モジュールを利用して監査結果を取得し、記憶モジュールを利用して監査結果を記憶する。この監査プラットフォームは、任意タイプのビジネスを監査してもよく、そして、ゲートウェイ開発人員の人力コストを低減し、コード冗長性を低減させ、かつビジネスコードのメンテナンス性を向上することができる。

本願の実施例が提供したビジネス監査報知方法がよりよく理解されるために、以下、ユーザ端末、ゲートウェイ及び監査プラットフォームを合わせて、ビジネス監査報知方法をさらに紹介する。

図１２は、本実施例が提供したビジネス監査報知方法のフローチャートである。図１２に示すように、ビジネス監査報知方法は、
ユーザ端末がゲートウェイの提出モジュールに操作要求を送信するステップ１２０１を含む。

ただし、操作要求は、ユーザ身元識別子、ミニアプリ識別子、操作タイプ（名称修正）及び名称パラメータ（ミニアプリの新しい名称）を含む。

ステップ１２０２において、ゲートウェイは、ユーザ身元を認証する。

本実施例において、ゲートウェイは、操作要求からユーザ身元識別子、ミニアプリ識別子を解析し、ユーザ身元識別子に基づいてミニアプリ識別子との権限関係を検証する。ユーザ身元識別子が操作権限を持っていない場合、ユーザ端末に検証失敗メッセージを返送する。ユーザ身元識別子が操作権限を持っている場合、ユーザ端末に検証成功メッセージを返送し、後続のステップを実行し、又は、ユーザ端末に検証成功メッセージを返送せずに、直接に後続のステップを実行する。

ステップ１２０３において、ゲートウェイの監査提出手段は、監査プラットフォームにビジネス監査任務を送信する。

ビジネス監査任務は、ゲートウェイが操作要求に基づいて得られた監査任務である。ビジネス監査任務は、ミニアプリ識別子、操作タイプ（名称修正）及び名称パラメータを含む。ユーザ身元に対する検証が成功した場合、ゲートウェイは、監査プラットフォームにビジネス監査要求を送信する。

ステップ１２０４において、監査プラットフォームは、ゲートウェイに監査任務識別子を返送する。

本実施例において、監査プラットフォームは、ビジネス監査任務を受信した後、このビジネス監査任務のために１つの唯一の識別子を割り当てって、後続のフローで使用されることに供する。

ステップ１２０５において、ゲートウェイは、報知テンプレートライブラリから監査報知テンプレートを取得する。

本実施例において、監査報知テンプレートは、開発者又は第３者の事業者により予め設定され、報知テンプレートライブラリに記憶されているテンプレートである。

ステップ１２０６において、監査任務識別子、ユーザ身元識別子、ビジネス監査提出時間、監査報知テンプレート、操作パラメータ及び監査結果メッセージ項目に基づいて、報知待ちメッセージを生成する。

本実施例において、ゲートウェイは、監査プラットフォームより返送された監査任務識別子に基づいて、報知テンプレートライブラリから監査報知テンプレートを取得し、ユーザ端末により送信されたユーザ身元識別子、ビジネス監査提出時間及び操作パラメータ、並びに監査結果メッセージ項目を合わせて、報知待ちメッセージを生成する。

ステップ１２０７において、監査プラットフォームは、監査人員の監査結果を受信する。

本実施例において、監査プラットフォームは、監査人員に操作パラメータを表示し、監査人員は、操作パラメータに従ってビジネス監査要求を監査し、監査結果を監査プラットフォームに伝送する。

ステップ１２０８において、監査プラットフォームは、監査結果をメッセージキューに記憶する。

ステップ１２０９において、ゲートウェイは、メッセージキューから監査結果を取得する。

ステップ１２１０において、ゲートウェイは、監査任務識別子に基づいて、報知待ちメッセージライブラリから対応する報知待ちメッセージを取得し、監査結果及び報知待ちメッセージを組み合わせて、報知メッセージを取得する。

ステップ１２１１において、ゲートウェイは、プッシュアドレスライブラリからユーザ端末のプッシュアドレスを取得する。

本実施例において、ユーザ端末のプッシュアドレスは、ユーザによりプッシュアドレスライブラリに予め配置されたものである。

ステップ１２１２において、ゲートウェイは、報知メッセージをプッシュアドレスに従ってユーザ端末にプッシュする。

本願の実施例によれば、本願は、電子機器及び読取可能な記憶媒体をさらに提供した。

図１３は、本願の実施例によるビジネス監査報知の方法の電子機器のブロック図である。図１３に示すように、電子機器とは、様々な形式のデジタルコンピュータ、例えば、ラップトップ型コンピュータと、デスクトップコンピュータと、ワークステーションと、パーソナル・デジタル・アシスタントと、サーバと、ブレードサーバと、大型コンピュータと、他の適宜なコンピュータとを表す旨である。電子機器は、様々な形式の移動装置、例えば、パーソナル・デジタル・アシスタントと、セルラー電話と、スマートフォンと、ウェアラブル機器と、他の類似する計算装置とを表してもよい。本明細書に示す部品と、それらの接続及び関係と、それらの機能とは単に例示であり、本明細書で説明した及び／又は要求した本願の実現を限定することを意図しない。

図１３に示すように、この電子機器は、１つ又は複数のプロセッサ１３０１、メモリ１３０２、及び各部品を接続するための、高速インターフェース及び低速インターフェースを含むインターフェースを備える。各部品は、異なるバスで互いに接続され、且つ共通のメインボード上に実装されてもよく、又は必要に応じて他の方式で実装されてもよい。プロセッサは、電子機器内で実行されるコマンドを処理することができ、メモリに記憶されて、外部入力・出力装置（例えば、インターフェースに結合する表示機器）上に図形ユーザインターフェース（Ｇｒａｐｈｉｃａｌ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ，ＧＵＩ）の図形情報を表示するコマンドを含む。他の実施形態においては、必要に応じて、複数のプロセッサ及び／又は複数のバスを複数のメモリと一緒に使用してもよい。同様に、複数の電子機器を接続して、各機器が一部の必要な操作を提供してもよい（例えば、サーバアレー、一組のブレードサーバ、又はマルチプロセッサシステムとする）。図１３においては、１つのプロセッサ１３０１を例とする。

メモリ１３０２は、本願が提供した非一時的なコンピュータ読取可能な記憶媒体である。ただし、前記メモリには少なくとも１つのプロセッサにより実行され得るコマンドが記憶されており、前記少なくとも１つのプロセッサに本願が提供したビジネス監査報知の方法を実行させる。本願の非一時的なコンピュータ読取可能な記憶媒体は、コンピュータコマンドを記憶しており、このコンピュータコマンドは、コンピュータに本願が提供したビジネス監査報知の方法を実行させるものである。

メモリ１３０２は、非一時的なコンピュータ読取可能な記憶媒体として、非一時的なソフトウェアプログラム、非一時的なコンピュータ実行可能なプログラム及びモジュール、例えば本願の実施例におけるビジネス監査報知の方法に対応するプログラムコマンド・モジュールを記憶するものである。プロセッサ１３０１は、メモリ１３０２に記憶されている非一時的なソフトウェアプログラム、コマンド及びモジュールを実行することで、サーバの各種の機能アプリケーション及びデータ処理を実行し、即ち上記方法実施例におけるビジネス監査報知の方法を実現する。

メモリ１３０２は、プログラム記憶領域及びデータ記憶領域を含んでもよく、ただし、プログラム記憶領域は、オペレーティングシステム、少なくとも１つの機能に必要なアプリケーションプログラムを記憶してもよく、データ記憶領域は、ビジネス監査報知による電子機器の使用により生成されたデータなどを記憶してもよい。また、メモリ１３０２は、高速ランダムアクセスメモリを含んでもよく、非一時なメモリ、例えば少なくとも１つの磁気ディスク記憶デバイス、フラッシュメモリデバイス、又は他の非一時的なソリッド記憶デバイスを含んでもよい。一部の実施例において、メモリ１３０２は選択的にプロセッサ１３０１に対して遠隔に設置されたメモリを含み、これらの遠隔メモリが、ネットワークを介して電子機器に接続されてもよい。上記ネットワークの例示は、インターネット、イントラネット、ローカルエリアネットワーク、移動通信ネットワーク及びそれらの組合を含むが、これらに限られない。

ビジネス監査報知の方法の電子機器は、入力装置１３０３及び出力装置１３０４をさらに含んでもよい。プロセッサ１３０１、メモリ１３０２、入力装置１３０３及び出力装置１３０４は、バス又は他の方式で接続されてもよく、図１３においてバスを介して接続されることを例とする。

入力装置１３０３は、入力されたデジタル又はキャラクター情報を受信し、ビジネス監査報知方法の電子機器のユーザ設置及び機能制御に関わるキー信号入力を発生してもよく、例えば、タッチスクリーン、キーパッド、マウス、トラックパッド、タッチパッド、インジケーターロッド、１つ又は複数のマウスボタン、トラックボール、レバーなどの入力装置である。出力装置１３０４は、表示デバイスと、補助照明装置（例えば、ＬＥＤ）と、触覚フィードバック装置（例えば、振動モーター）などを含んでもよい。この表示デバイスは、液晶ディスプレー（ＬＣＤ）と、発光ダイオード（ＬＥＤ）ディスプレーと、プラズマディスプレーとを含むが、これらに限られない。一部の実施形態において、表示デバイスはタッチスクリーンであってもよい。

ただし説明したシステム及び技術の各実施形態は、デジタル電子回路システム、集積回路システム、専用ＡＳＩＣ（専用集積回路）、コンピュータハードウェア、ファームウェア、ソフトウェア、及び／又はそれらの組合せで実現されてもよい。これらの各実施形態は、１つ又は複数のコンピュータプログラムで実施されることを含んでもよく、この１つまたは複数のコンピュータプログラムが、少なくとも１つのプログラマブルプロセッサを含むプログラマブルシステム上で実行及び／又は解釈されてもよく、このプログラマブルプロセッサは、専用又は共通のプログラマブルプロセッサであってもよく、記憶システムと、少なくとも１つの入力装置と、少なくとも１つの出力装置とからデータと命令とを受信し、データと命令とをこの記憶システムと、この少なくとも１つの入力装置と、この少なくとも１つの出力装置とに伝送してもよい。

これらの計算プログラム（プログラム、ソフトウェア、ソフトウェアアプリケーション、又はコードとも称する）は、プログラマブルプロセッサの機械命令を含み、高級プロセス及び／又はオブジェクト指向のプログラミング言語、及び／又はアセンブリ・機械言語によってこれらの計算プログラムを実施してもよい。本明細書で使用した術語「機械読取可能な媒体」及び「コンピュータ読取可能な媒体」とは、機械命令及び／又はデータをプログラマブルプロセッサに提供するための任意のコンピュータプログラム製品、機器、及び／又は装置（例えば、磁気ディスク、光ディスク、メモリ、プログラマブルロジックデバイス（ＰＬＤ））を意味しており、機械読取可能な信号である機械命令を受ける機械読取可能な媒体を含む。術語「機械読取可能な信号」とは、機械命令及び／又はデータをプログラマブルプロセッサに提供するための任意の信号を意味している。

ユーザとのインタラクションを提供するために、コンピュータでただし説明したシステム及び技術を実施してもよく、このコンピュータは、ユーザに情報を表示するための表示装置（例えば、ＣＲＴ（陰極線管）又はＬＣＤ（液晶ディスプレー）モニタ）と、キーボード及び指向装置（例えば、マウス又はトラックボール）とを有し、ユーザは、このキーボード及びこの指向装置によって、入力をコンピュータに提供することができる。他の種類の装置は、ユーザとのインタラクションを提供するためのものであってもよく、例えば、ユーザに提供するフィードバックは、任意の形式のセンサーフィードバック（例えば、視覚フィードバック、聴覚フィードバック、又は触覚フィードバック）であってもよく、任意の形式（声入力、語音入力、又は触覚入力を含む）でユーザからの入力を受信してもよい。

ただし説明したシステム及び技術は、バックグラウンド部品を含む計算システム（例えば、データサーバとする）、又はミドルウェア部品を含む計算システム（例えば、アプリケーションサーバ）、又はフロントエンド部品を含む計算システム（例えば、グラフィカル・ユーザー・インターフェース又はネットワークブラウザを有するユーザコンピュータ、ユーザはこのグラフィカル・ユーザー・インターフェース又はこのネットワークブラウザを介してただし説明したシステム及び技術の実施形態とインタラクトすることができる）、又はこのようなバックグラウンド部品、ミドルウェア部品、或いはフロントエンド部品の任意の組合せを含む計算システムで実施されてもよい。任意の形式又は媒体のデジタルデータ通信（例えば、通信ネットワーク）を介してシステムの部品を相互に接続してもよい。通信ネットワークの例示は、ローカルエリアネットワーク（ＬＡＮ）と、広域ネットワーク（ＷＡＮ）と、インターネットとを含む。

コンピュータシステムは、クライアントとサーバとを含んでもよい。クライアントとサーバとは、一般的に互いに離れて、且つ通常に通信ネットワークを介してインタラクトする。相応するコンピュータで実行されるとともに、互いにクライアント-サーバの関係を有するコンピュータプログラムによって、クライアントとサーバとの関係を形成する。

本願の実施例は、プロセッサによって実行される際に、上記いずれかのビジネス監査報知方法を実現するコンピュータプログラムを記憶しているコンピュータ読取可能な媒体を提供した。

上記に示した様々な形式のフローを利用して、ステップを並び替え、追加又は削除することができると理解すべきである。例えば、本願に記載された各ステップは、並行に実行されてもよいし、順に実行されてもよいし、異なる順序で実行されてもよく、本願が開示した技術案が所望する結果を実現できる限り、本文はただし限定しない。

上述した具体的な実施形態は、本願の保護範囲に対する限定を構成しない。当業者は、設計要求や他の要因に応じて、さまざまな修正、組合、サブ組合及び置換を行うことができると理解すべきである。本願の趣旨及び原則の範囲内になされた任意の修正、等価な置換、改進などは、いずれも本願の保護範囲内に含まれるべきである。

Claims (21)

1. ユーザ端末の操作要求に応答して監査プラットフォームにビジネス監査要求を送信することと、
   前記監査プラットフォームにより返送された監査任務識別子に基づいて報知待ちメッセージを生成することと、
   取得された監査結果及び前記報知待ちメッセージに基づいて、監査報知メッセージを生成することと、
   前記監査報知メッセージを前記ユーザ端末にプッシュすることと、を含む、
   ことを特徴とするビジネス監査報知方法。
2. 前記ユーザ端末の操作要求に応答して監査プラットフォームにビジネス監査要求を送信することは、
   前記操作要求を解析して、ユーザ身元識別子及びミニアプリ識別子を取得することと、
   前記ユーザ身元識別子及び前記ミニアプリ識別子に基づいて、ユーザ身元を検証することと、
   前記ユーザ身元の検証が成功した場合、前記監査プラットフォームにビジネス監査要求を送信することと、を含む、
   ことを特徴とする請求項１に記載の方法。
3. 前記監査プラットフォームにより返送された監査任務識別子に基づいて、報知待ちメッセージを生成することは、
   前記操作要求の操作タイプに基づいて、報知テンプレートライブラリから前記操作タイプに整合する監査報知テンプレートを取得することと、
   前記監査報知テンプレート及び前記監査任務識別子に基づいて、報知待ちメッセージを生成することと、を含む、
   ことを特徴とする請求項１に記載の方法。
4. 前記監査報知テンプレートに基づいて、報知待ちメッセージを生成した後、前記方法は、
   前記報知待ちメッセージを報知待ちメッセージライブラリに記憶することをさらに含む、
   ことを特徴とする請求項３に記載の方法。
5. 前記監査結果及び前記報知待ちメッセージに基づいて、監査報知メッセージを生成することは、
   前記監査任務識別子に基づいて、前記報知待ちメッセージライブラリから前記監査任務識別子に対応する前記報知待ちメッセージを取得することと、
   前記監査結果と前記報知待ちメッセージとを組み合わせて、前記監査報知メッセージを生成することと、を含む、
   ことを特徴とする請求項４に記載の方法。
6. 前記報知待ちメッセージに係るフィールドは、監査任務識別子、ユーザ身元識別子、操作パラメータ、前記ビジネス監査要求を提出する時間、前記操作タイプに整合するテンプレートである監査報知テンプレート及び前記監査結果を書き込むためのフィールドである監査結果メッセージ項目を含む、
   ことを特徴とする請求項１に記載の方法。
7. 前記監査結果は、前記監査結果を記憶するための行列であるメッセージキューから取得される、
   ことを特徴とする請求項１に記載の方法。
8. 前記監査報知メッセージを前記ユーザ端末にプッシュすることは、
   プッシュアドレスライブラリから前記ユーザ端末のプッシュアドレスを取得することと、
   前記プッシュアドレスに従って、前記監査報知メッセージを前記ユーザ端末にプッシュすることと、を含む、
   ことを特徴とする請求項１に記載の方法。
9. 前記監査報知メッセージを前記ユーザ端末にプッシュすることは、
   所定のプッシュ回数及び所定の時間間隔に従って、前記ユーザ端末に前記監査報知メッセージをプッシュすることを含む、
   ことを特徴とする請求項１に記載の方法。
10. ゲートウェイがユーザ端末の操作要求に応答して送信したメッセージであるビジネス監査要求を受信することと、
    監査結果を取得して記憶することで、前記ゲートウェイが、前記監査結果と、ゲートウェイが前記ビジネス監査要求に対して生成したメッセージである報知待ちメッセージとに基づいて、監査報知メッセージを生成することに供することと、を含む、
    ことを特徴とするビジネス監査報知方法。
11. 前記監査結果を取得して記憶することは、
    前記監査結果を受信して、前記監査結果をメッセージキューに記憶することを含む、
    ことを特徴とする請求項１０に記載の方法。
12. 前記ビジネス監査要求を受信した後、前記方法は、
    ゲートウェイに、監査任務の唯一の識別子である監査任務識別子を返送することをさらに含む、
    ことを特徴とする請求項１０に記載の方法。
13. ユーザ端末の操作要求に応答して、監査プラットフォームにビジネス監査要求を送信し、前記監査プラットフォームにより返送された監査任務識別子に基づいて、報知待ちメッセージを生成するように配置されている提出モジュールと、
    取得された監査結果及び前記報知待ちメッセージに基づいて監査報知メッセージを生成し、前記監査報知メッセージを前記ユーザ端末にプッシュするように配置されているプッシュモジュールと、を含む、
    ことを特徴とするゲートウェイ。
14. 前記提出モジュールは、
    監査プラットフォームにビジネス監査要求を送信するように配置されている監査提出手段と、
    前記監査プラットフォームにより返送された監査任務識別子に基づいて、報知待ちメッセージを生成するように配置されている第１の生成手段と、を含む、
    ことを特徴とする請求項１３に記載のゲートウェイ。
15. 前記提出モジュールは、
    前記操作要求を解析して、ユーザ身元識別子及びミニアプリ識別子を取得するように配置されている解析手段と、
    前記ユーザ身元識別子及び前記ミニアプリ識別子に基づいてユーザ身元を検証するように配置されている検証手段と、を含む、
    ことを特徴とする請求項１４に記載のゲートウェイ。
16. 前記プッシュモジュールは、
    取得された監査結果及び前記報知待ちメッセージに基づいて、監査報知メッセージを生成するように配置されている第２の生成手段と、
    前記監査報知メッセージを前記ユーザ端末にプッシュするように配置されているプッシュ手段と、を含む、
    ことを特徴とする請求項１３に記載のゲートウェイ。
17. 前記プッシュモジュールは、
    監査結果を記憶するための行列であるメッセージキューから前記監査結果を申し込み、前記監査結果を前記第２の生成手段に伝送するように配置されている申し込み手段をさらに含む、
    ことを特徴とする請求項１６に記載のゲートウェイ。
18. 前記操作要求のタイプに対応する監査報知テンプレートを記憶するように配置されている報知テンプレートライブラリと、
    ユーザにより予め配置された報知を受信するアドレスである、前記ユーザ端末のプッシュアドレスを記憶するように配置されているプッシュアドレスライブラリと、さらに含む、
    ことを特徴とする請求項１３に記載のゲートウェイ。
19. 少なくとも１つのプロセッサと、
    前記少なくとも１つのプロセッサと通信接続するメモリとを含む電子機器であって、
    前記メモリに、前記少なくとも１つのプロセッサによって実行され得るコマンドが記憶されており、前記コマンドが前記少なくとも１つのプロセッサによって実行されることで、前記少なくとも１つのプロセッサが請求項１～９、１０～１２のいずれか一項に記載の方法を実行することができる、
    ことを特徴とする電子機器。
20. コンピュータに請求項１～９、１０～１２のいずれか一項に記載の方法を実行させるためのコンピュータコマンドを記憶している、
    ことを特徴とする非一時的なコンピュータ読取可能な記憶媒体。
21. プロセッサによって実行されることで、請求項１～９、１０～１２のいずれか一項に記載の方法を実現するコンピュータプログラムを含むコンピュータプログラム製品。

Images