> For the complete documentation index, see [llms.txt](https://releaseowl.gitbook.io/releaseowl-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://releaseowl.gitbook.io/releaseowl-docs/releaseowl-user-guide/sap-integration-suite/cpi-test-generator.md). # CPI Test Generator The CPI Test Generator helps automate the process of testing SAP Cloud Platform Integration (CPI) Integration Flows (iFlows). It allows you to generate, execute, and review test results, making the integration testing process efficient and error-free. This guide will walk you through the steps for deploying, configuring, testing, and mocking your iFlows using the ReleaseOwl platform. ### **Prerequisites** **1. SAP Process Integration Runtime Service Instance** * Navigate to **Instances and Subscriptions** and click **Create**.

* Fill in the following details: * **Service:** SAP Process Integration Runtime * **Plan:** integration-flow * **Runtime Environment:** Cloud Foundry * **Space:** Dev * **Instance Name:** Choose a suitable name * Click **Next**, then **Create** to set up the instance.

2. Create Service Key 3. Enable Custom Idp 4. Enable Test Automation in ReleaseOwl CPI Environment Configuration 5. Update the OAuth credentials and Instance URLs in the ReleaseOwl CPI Environment using the details from the Service Key in SAP BTP Cockpit.

### **Generating Test Cases** **Enable Trace in Artifact Runtime Log Configuration** * In **SAP BTP Cockpit**, go to **Integration and APIs** and select the **iFlow** you want to test. * Navigate to **Artifact Details** and change the **Log Level** to **Trace** to track detailed logs during testing. * Trigger the iFlow with the expected input using **Postman** or another tool.

### **Generate Test Cases** 1. Navigate to **CPI Test Generator**. 2. Go to the **Test Cases** section. 3. Click **Generate Test Cases** to create test cases.

4. Select the **Artifact Name** for the iFlow.

5. After selecting the required iFlow, click **Fetch Activity Messages** to retrieve the activity messages associated with the iFlow.

6. Once the fetching process is completed and the status changes to **Completed**, click **Close**.

7. Select the required **Message Group ID**. 8. Click **Generate Test Case**.

9. A pop-up window will appear to create the test case. * Enter the **Test Case Name**. * Ensure that special characters are not used while naming the test case.

10. Once the test case is created, click the **Actions** button and select **Edit**.

11. This will retrieve messages from the latest iFlow execution: * The **first message** will be considered the **input message**. * The **remaining messages** will be treated as **output messages**. 12. Click the **Model Step Id** to view the messages.

**Active Button** * If you need to **temporarily disable** the execution of a test case, uncheck the **Active** button. * Once the issue is resolved, re-enable the test case by checking the **Active** button again.

**Mock Endpoints** * When enabled, ReleaseOwl **mocks all receiver channels** in the iFlow with **HTTPS receivers** pointing to the **ReleaseOwl mock service**. * **ReleaseOwl** creates a new iFlow by applying the prefix defined during environment creation to both the iFlow name and the package name. * The mock service simulates responses returned by external calls using recorded messages from the test case generation. * This allows integration flow testing **without relying on actual external APIs**.

### **Executing Test Cases** 1. Click **Run** to execute the test case.

2. After execution, click the **Actions button (···)** and select **Last Test Results** to view test case results. 3. You can view the executed test cases, including details such as: * **Run ID** * **Artifact Name** * **Environment**

#### **Other Action Buttons** **Run on button:** It provides an option to select a particular environment before executing the test case.

**Test Runs:** Displays all test runs with timestamps, executed artifact versions, and environments.

**Comparing Test Run Messages** * **Expected Output:** The message recorded during test case creation. * **Actual Output:** The message from the current test execution. * **Differences:** Differences between the **header** and **exchange properties** of the expected and actual messages. * **Added Label:** Indicates unmatched paths where the **expected output** is **null**, improving message comparison visibility in the test results.

* The **Ignore List** allows you to exclude specific **paths, header properties, and exchange properties** (e.g., timestamps, generated IDs, etc.).

#### **Editing and Updating Test Cases** * If a test case needs adjustments (e.g., missing parameters in the iFlow), click **Edit** to modify it. * If steps are added or removed in the actual iFlow, the messages in the testcase should also be updated. Click on Update Messages will execute the iFlow using the input from the testcase, which will display the latest messages from the trace. * The user can review these messages and update the testcase with the new message steps. Click on the Save button to save the updated messages to the testcase.

#### **Mock Endpoints** * When enabled, ReleaseOwl **mocks all receiver channels** in the iFlow with **HTTPS receivers** pointing to the **ReleaseOwl mock service**. * **ReleaseOwl** creates a new iFlow by applying the prefix defined during environment creation to both the iFlow name and the package name. * The mock service simulates responses returned by external calls using recorded messages from the test case generation. * This allows integration flow testing **without relying on actual external APIs**.

#### **Supported Sender Adapters** Test cases can be executed against iFlows using the following sender adapters: * **HTTP Adapter** * **SOAP Adapter** * **IDoc Adapter** * **Process Direct Adapter** * **JMS Adapter** ### **Running Test Cases for Process Direct and JMS Adapters** 1. **Process Direct Adapter and JMS Adapter** do not have HTTP endpoints, so test cases cannot be executed directly. 2. To test them, **import the CPI Connector Package** provided by ReleaseOwl into your **CPI tenant**. [86KBReleaseOwl Integrations.ziparchive](https://1890383800-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FDWyxe6hm5vqosFaByVgs%2Fuploads%2FSoq8ezi7D2ASogp1Jmzd%2FReleaseOwl%20Integrations.zip?alt=media\&token=ca7a467a-9cf2-4e1f-b2ba-e4e1bdbedd97) 3. After importing the package, **deploy the iFlow artifacts** so they can have endpoints. ### **Mocking Test Cases** ReleaseOwl mocks all the receiver channels in the iFlow with https receivers pointing to ReleaseOwl mock service. #### **Mocking Steps:** 1. **Edit the test case** and enable **Mock Endpoints** to simulate receiver endpoints using the HTTP receiver provided by ReleaseOwl.

2. Run the test case with mock enabled. 3. **Mock Package and iFlow:** A mock package and mock iFlow are created in the CPI tenant using the prefix defined during environment creation. #### **Test Results after Execution:** * **Executed on Artifact ID:** Displays the artifact name against which the test case was executed. * **Executed Artifact Version:** Shows the version of the artifact used for the test case execution.

--- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://releaseowl.gitbook.io/releaseowl-docs/releaseowl-user-guide/sap-integration-suite/cpi-test-generator.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.