...最初の接続の後、ゲートウェイを作成し、「バリケードの反対側で」技術専門家と対話する統合部門を作成することにしました。 部門長は、不測の事態を予測するように指示されました...
以下に書かれているものはすべて、完全な主観性であり、ロシアの詳細、私が働いていた会社の業界、個々の組織の行動のごみです。
どういうわけかそれはすべて動作します...
最初は、向こう側にExcelタブレットよりも高度な情報システムがない（最高の状態）ことを知ったとき、私の髪は逆立ちしていました。 しかし、結局のところ、これらはベストパートナーの一部です（ベストパートナーの2番目のカテゴリは、プロトコルを実装したものです）。 情報交換の問題を解決するだけでなく、パートナーのビジネスをある程度自動化する独自の情報システムを非常に迅速に作成し、カルマでプラスを獲得しました。
しかし、「技術的に進歩した」人々は、ほとんどの問題を解決しました。 記述された仕様に従って作業を行ったパートナーはほとんどいませんでした。システムのマイナーだがトリッキーな順列または「文書化されていない機能」から仕様への非準拠を完了するまで。 ちなみに、説明（少なくとも一部）がまったくなかった場合は、状況の適切な組み合わせと見なされました。 接続したい場合は、ここがあなたにとっての「穴」であることが判明しました-接続します（「穴」はパートナーのサイトの個人アカウントであることが簡単に判明する可能性があります）。
極端な例：パートナーからプロトコル（SOAP）が提供されました。 OK、ここにJava、ここにJCP（GOST EDSがあったため）-私たちは働いています。 ゲートウェイが作成され、すべてがテストエミュレーターで機能します。パートナーとのテストに合格します。 そして...あなたはどう思いますか？ 動作しません！ 彼らは3か月間理由を検索しました（パートナーのサポートは非常に緩慢に反応したため、2社のリーダーシップレベルで接続の問題を解決する必要がありました）。 その一方で、SOAPは「小さな機能」で実装されていることが判明しました。代わりに
<tagName></tagName>
送信する必要があります
<tagName><\tagName>
しかし、JCPはどうでしょうか？ 必要なかったのは、 反対側には実装がありませんでした。
他の極端な例：営業部がプロトコルを持ち込みます。 プロトコルが実装され、パートナーとの共同テスト（！）が完了しました。生産を有効にする必要があります。
別のパートナーはパートナーとこれを行っていますが、実際には、実装したプロトコルが自社のプロトコルであることを認識していません。 結果：別のプロトコルを実装するか、nか月待機します（正確な数字は覚えていませんが、10か月程度）。
最初のルール ：仕様に従って実装できないものはすべて、仕様に従って実装されません。
結論 ：パートナーからできるだけ早くテストゲートウェイを取得し、個々の部分の準備ができたら実装されたプロトコルをテストすることが非常に重要です。 これは、2番目のストーリーが示しているように、常に役立つとは限りません。
男の子はいましたか？
パートナーは、受信したデータを受信し、最も重要なこととして、受信したデータを処理できますか？ そう思うなら、それは世界を新たに見る時です。
パートナーの1人がリクエストの10〜20％を逃しました。 さて、どうやって見落としたのか...受け入れましたが、処理しませんでした。 これは彼らのシステムの機能であり、機能として宣伝されました。 私は問題を少し単純化しました 「遅延データ処理」は一部のタイプのリクエストのみであり、リモート側のムードに応じて機能しましたが、本質は変わりませんでした。 繰り返しますが、「リクエストが正常に受信されました」という応答コードを受信したことに注意してください（「リクエストが正常に完了しました」という応答コードはありませんでした）。 もちろん、プロトコルの説明では、この機能は考慮されていません。
別のパートナーは、新しいリクエスト（XMLプロトコル、HTTPトランスポート）の受信について私たちに通知しましたが、リクエストを受け入れるかどうかに特に関心はありませんでした。
「どのように」というトピックについて、パートナー企業（技術ディレクターおよび共同ディレクター）の経営陣と話をしたとき、面白い冗談がありました。 実際、私たちの側では（そのような不正に対応して）要求が5分に1回の頻度で実行されました。「私たちにニュースはありますか？」そしてそれら。 パートナーのディレクターがdosを呼び出し、「私たちの側で修正」という指示で私たちをブロックしました（当然、切断後ではなく、パートナーのサポートに連絡した後にのみ指示を受け取りました）。 私はコマーシャルディレクターとコミュニケーションをとるときにすべての「魅力」と説得力のある議論を結び付け、私たちが私たちの側ですべてを正しくしていることに同意しました（彼はまだテクニカルディレクターの位置を知りませんでした）。 その結果、comからの回答。 ディレクターとそれら。 ディレクターは両方とも同意の要求でメールに行きました。 1時間後、私たちの計画に従って電源が入りました。
ルール2 ：要求の正常な受信に関する（および、要求の正常な処理に関する）答えは、要求が実際に正常に処理されることを必ずしも意味しません。
結論 ：リクエストが正常に完了したことを別の方法で確認する必要があります（もちろん、可能であれば）。
あなたは信頼できる保護下にあります。
SSL証明書についてはさらに詳しくなりますが、私は1つの面白い話に言及するしかありません。
SSL暗号化を含むプロトコルを取得しました。 すべては機能し、テストは合格しましたが、...間違った証明書を使用しました。
少し調査した結果、リモート側は証明書をまったく検証しないことが判明しました。
別のパートナー（私たちのプロトコルに従って働いた）は、リクエスト例を文字通り受け入れすぎて、テスト中にサンプルから署名を送信しました（明らかに、セクションN「メッセージの署名」をマスターしませんでした）。 当然、「何も機能しない」という言葉で、私たちのビジネスは統合部門（その時点で既に存在していました）に突き当たりました。
3番目のパートナーは、別の驚きを持ち出しました。一度、パートナーの個人アカウントを入力すると、非常に大きな合計があり、トランザクションは私たちのものではないことに気付きました。 判明したように、特定の状況下で、パートナーはすべてのパートナーのシステムに関する情報を個人アカウントに送信しました。 彼らは修正することを約束し、それは二度と起こらないでしょう。 ええ、今。 1か月後、同じ問題に遭遇しました。 これは、パートナー企業とそのすべての顧客の売上高に関するインサイダーレポートをうっかり受け取った方法です。
そのようなことがあり、 3-D Secureと呼ばれます。 銀行の側に実装されています。
ある晴れた日、商取引が私に近づき、3Dセキュアが機能しないと報告します（実際、それは私の問題ではありませんが、誰が問題に取り組むべきか誰も知らなければ、彼らは私のところに来ました）。 どうしてうまくいかないの？ うまくいきます。ページの一番下（ブラウザで2つの空白ページをスクロールするため）にのみ、白地にグレーの「キャンセル」ボタンがあります（3DSなしで支払いをスキップします）。 そのため、
ルール3 ：自己実装されたアクセス制限システムは機能しません。
結論 ：標準的で実績のある手段でセキュリティ対策をさらに強化する必要があります（ただし、ルール5を参照）。
太平洋の衛星。
携帯電話で電話を受けたら：「こんにちは、アレクセイ！ これは会社****（ここでは有名な会社の名前）です。 弊社製品****のリクエストがあります。」 私は本当にこの製品のリクエストを残した場合、 私はそれについてここに書いていないことを理解していると思います 。 結局のところ、2分前に、私たちのビジネスも同様の電話を受けました。
状況は単純であることが判明しました。システムの焼きたての機能を商業的にテストした結果、パートナーへの転送を目的としたレジストリが作成されました。 そして、パートナーはこのレジストリを受け取りました（レジストリの形式を確認するためのリクエストとともに、相手側からマネージャーに電子メールで手動で送信されました）。 リモート側で何が起こったのかわかりませんが、その結果、彼はどういうわけか処理を始めました。
別のケース：ある時点で、システムは2つの技術サイト（ビジネス上の理由で）で同時に展開され、あちこちで動作しました。 しばらくして、一部のお客様から、リクエストが処理されなかったという苦情を受けました。 突然。 これがどのように行われるかはわかりませんが、何らかの理由で、テクノロジープラットフォームに応じて、パートナーの実稼働サーバーまたはテストのいずれかにリクエストが送信されました。 サポートが両方のサイトからtracerouteを実行することを決定するまで長い間その理由を発見し、サイトによっては、同じIPアドレスに送信されたリクエストが異なるサーバーに送られることが判明しました（サイトの1つからのリクエストの場合、クライアントのネットワーク内では、リクエストはさまざまなルーターを通過しました）。
ルール4 ：要求が間違った方向に進む可能性がある場合、間違った方向に進みます。
結論 ：ルール2を参照してください。
誰がここにいますか？
評判が良く実績のあるソリューションを信頼することは可能ですか？ これらのソリューションの構成がパートナーの手にある場合、そうではないことを既に理解していると思います。 上記のルーティングの話、SSLについてもですが、ここにさらに2つあります。
gateXXX.comp_name.com（XXXは成人ではなく、ゲートウェイのタイプ）に類似したアドレスを持つゲートウェイが与えられました。 制作の最初の週の後、パートナーのDNSが落ちたと言う必要がありますか？ DNSを上げた後、IPアドレスを逆の順序で与えたと言うのは不必要だと思います。 しかし、この瞬間にはすでに「シャッフル」されており、プライマリDNSサーバーを信頼していませんでした。
通常、SSLは別の曲です。
まだ証明書を信頼していますか？ それから私たちはあなたに行きます 。 まあ、箱から出してすぐにパートナーが少なくとも何らかの種類のデータ保護を持っていた場合（少なくともキーとmd5の形でのなりすましから）。 一般に、情報セキュリティ部門全体（他のセキュリティ部門と並行して機能する）があり、そのレベルで暗号化のアイデアを推進しました。 しかし、非常に頻繁にこれは役に立たなかった。 一部のパートナーは、メッセージ本文から単純にmd5を転送することを申し出ました。誰かが、せいぜい自己署名証明書を使用し、最悪の場合はgodaddyから、別のドメインに発行しました。 GOSTによる暗号化（およびサポートが機器をどのように構成したか）については書きたくありません。
確かにわかっていたことの1つは、
ルール5 ：パートナーが既に有名なシステムをセットアップしている場合、これを別のシステムと考えてください。
結論 ：創意工夫とストレス耐性（サポートとゲートウェイの両方）。
（再び）何も動作しません。
ああ、どれくらいの頻度で私はこのフレーズを聞いた... Nooooo ...会計士ではなく、反対側の技術者から。
ルール6 ：何かが「壊れている」場合、正確には何がわからないでしょう。
結論 ：完全なログと便利なログ表示。
白くてふわふわ
いいえ、私たちはとても白くふわふわしていたので、すべてがうまくいったとは言いたくありません。 当然、私たちは横棒にも遭遇しました。 私が書いていない非常に不愉快なものさえありました（私は最近、ビジネスほど技術にあまり取り組んでいなかったので）。 しかし、技術の順守、関連規格（および当社の！）の深い理解、プロトコル、責任、「全員のために」考える意欲-これらは統合部門の長の候補者の要件でした。
一般に、オンラインシステムとの統合は楽しく、刺激的で興味深いものです。 多くの優秀な専門家に会い、多くの興味深いプロトコルアーキテクチャとシステムを見ました。