統合テストとセキュリティ

統合の機能テストは、データが外部ソースからアプリケーションに正確に到着し、外部ソースに正しく書き込まれていることを確認するうえで不可欠です。また、すべてのコネクターについてエラー処理を行うことが推奨されています。

統合の機能テスト

REST統合の機能をテストするには、まずデータページを開き、システムでREST呼び出しに使用されているデータを検証してから、データページを実行して、返されるデータの種類を確認します。

SOAPコネクターの場合、機能テストは、ウェブサービスの機能について記述するウェブサービス記述言語（WSDL）を含んだエンドポイントURLを定義した時点で開始できます。

特定の郵便番号から緯度と経度の値を取得するSOAPコネクターがある場合を考えてみます。Pega Platform™では、エンドポイントURLを定義した後でWSDLが読み込まれ、使用可能なオペレーションのリストが表示されます。オペレーションを1つ選択して「Test 」をクリックすると、そのオペレーションのテストが開始され、データソースがリクエストアクションとレスポンスアクションの両方で期待されるノード名と値を返しているかどうかが確認されます。下の図はテストを示しています。

統合とそのデータページが設定されたら、「Actions > Run」をクリックして郵便番号を入力することで、統合の機能をテストできます。次の例では、この機能が適切に設定されている場合、正確な緯度と経度が返されます。

統合の単体テスト

「Convert to test」をクリックすると、統合の機能テストを統合のデータページに対する単体テストに変換できます。予想される実行時間のしきい値など、予想される結果のアサーションを追加します。次の例では、緯度と経度の値を取得するのにかかると予想される実行時間は1秒未満です。

Pega Platformでは、データ統合時にPega以外のシステムが保護されないため、取り込むデータが安全であることを確認する必要があります。データの保護とクレンジングを適切に行って、不正なコードが実行されたり、セキュリティベクターにSQLインジェクションなどの攻撃が仕掛けられたりするのを防ぐ必要があります。Pega Platformには、安全な統合を可能にするために次の設定が用意されています。 

• アウトバウンド呼び出しに必要なセキュリティ証明書のインストール。
• システムの許可リストへのさまざまなクラウド環境向けエンドポイントURLの追加。許可リストのアクセス権と承認されたエンドポイントURLについては、システム管理者と調整してください。 

データソース認証 

多くの場合、外部システムでは、リクエスト呼び出しの際に認証が必要となります。統合を初期設定するときに、新しい認証プロファイルを定義するか、既存の認証プロファイルをリクエストに使用できます。Test Data Sourceモーダルダイアログボックスで、「Authentication」タブをクリックして認証プロファイルを設定します。Test Data Sourceモーダルは、以下の画像のように表示されます。

証明書とプライベートキー

HTTPS経由でコンテンツを提供するウェブアプリケーションでは、多くの場合、認証が必要になります。ウェブサービスで安全なデータを受信するには、信頼できるクライアントとサーバーの両方が必要になる場合があります。 

多くの場合、転送されたコンテンツを暗号化および認証するには、クライアントシステム宛てに発行されたプライベートキーが必要です。また、Pega Platformでは、認証局から提供された証明書をクライアントシステムに保存する必要が生じることも少なくありません。 

デジタル証明書は、システムとユーザーがIDの認証に使用するIDログイン情報を含んだデータファイルです。認証局は、ウェブサーバーまたはサービスのIDを認証し、暗号化用のプライベートキーを使用して所有権の詳細を保護する、信頼できる外部エンティティです。たとえば、ウェブサービスでは、サービスからのデータ転送を可能にするために、インストールされた証明書だけでなく、プライベートキーも必要になる場合があります。これにより、受信するデータの真正性と安全性が保証されます。 

次の画像で「+」アイコンをクリックすると、証明書とプライベートキーの両方を必要とするウェブサービスから保護されたデータを取得する方法の詳細が表示されます。

Web applications that serve content over HTTPS can often require authentication. Receiving secure data for your web service may require both a trusted client and a server. 

Frequently, private keys issued to the client system are required for encryption and authentication of the transported content. Also, Pega Platform often needs certificates provided by Certificate Authorities to also be stored in the client system. 

Digital certificates are data files that contain identity credentials that help systems and users authenticate their identity. Certificate Authorities are external, trusted entities that authenticate identities and secure ownership details of a web server or service with private, cryptographic keys. For example, a web service may require not only an installed certificate but also a private key in order to allow data transfer from the service. This ensures that the data you receive is authentic and secure. 

Match the numbers to the following image to earn more about retrieving secured data from a web service requiring both certificates and a private key:

1. Certificates and keys installed on system: A certificate from a Certificate Authority is installed and a private key is saved on your system. 

2. System sends request: The system sends a request to the secured web service using credentials that include the certificate and private key. 

3. Secured web service: The web service is secured and will only accept requests from authenticated entities. 

4.  Web service checks certificate and key: The web service checks the request to determine if the requestor's identity is authenticated by a certificate and private key.

5. Validation of certificate and key: If the certificate and key are validated, the web service delivers the secured data. 

Pega Platform uses the keystore Rule Data-Admin-Security-Keystore to save certificates and private keys issued to the client.

Check your knowledge with the following interaction: