Test-driven development is a concept in the software development practice, where software development is closely tracked by repeatedly executing tests. In its pure form tests must even exist before the software itself.

In this blog post, I’m going to show you step by step how Process Integration Test can bring you one step towards test-driven development while developing a new integration flow. Even if pure form of test-driven development can’t be reached with the current means available in PIT, the procedure will help you to achieve better quality through high test coverage and by avoiding mistakes at the very early stage in the development process.

Use Case

Let’s assume I want to develop a new integration flow with complex routing conditions. To make sure, I formulated all conditions correctly and routing works as expected, I want to have a test message for each different condition path. As my integration flow is not yet productive, I do not have any sender who can send regular messages and though I can’t extract test messages into a test dataset in PIT.

Create an Integration Flow

I start at the very beginning in the Integration Designer perspective in NWDS and create a new integration flow, which has only one default, dummy receiver, and no conditions yet. I activate and deploy the integration flow.

Figure 1: Initial integration flow, yet without conditions and with dummy receiver

Create a Test Case

Right afterwards, I can create a new PIT test case directly from the Integration Designer perspective. I select the integration flow, choose “Create Test Case” from context menu and follow the steps in the wizard. One prerequisite for the generation wizard is that a connection to the desired PIT system is maintained in the Process Integration Test perspective and a suitable test system entity already exists (crucial: the name of the test system in PIT must be equal to the system name in Integration Designer). I select the checkbox in the last wizard step for automatic switch to ‘SAP Process Integration Test’ perspective.

Figure 2: Create a new PIT test case out of the integration flow

In the Process Integration Test perspective, the test case is added to the Test Catalog and the editor opens automatically. But instead of extracting message exchanges from the system into a test dataset (remember, there are no suitable messages in the system yet), I will create them manually using test data draft workbench. Later, I can create a test dataset containing these messages and assign it to the test case.

Figure 3: Test case created by wizard shown in PIT perspective

Create a Test Data Draft

With the help of the test data draft workbench, I can create many different test message exchanges for the integration flow and provide a suitable payload for each XPath condition and test the integration flow along the development process.

I open Test Data Draft Overview (in the NWDS perspective SAP Process Integration Test select menu Process Integration -> Test Data Draft Overview) and select “Create new test data draft” from the toolbar. I provide a name for the test data draft and assign my integration flow to it. Once the dialog is confirmed, the editor ‘Test Data Draft Workbench’ will open automatically.

Figure 4: ‘Create Test Data Draft’ wizard

In the test data draft workbench, I add my first message exchange draft manually using Add Message Exchange Draft -> Create New and insert my existing payload as content.

Figure 5: ‘Create new message exchange draft’ wizard

The new message exchange draft is shown in the list, its content is loaded and can be edited, if necessary.

Figure 6: ‘New’ message exchange draft in the test data draft workbench

Right afterwards, I process my message through the PI pipeline by selecting  “Process selected messages” and verify that my scenario with dummy receiver works. Processing through pipeline will generate a valid PIT message exchange with incoming and outgoing message exchange version.

Figure 7: Successfully processed message

Receiver Condition

In my aimed integration flow, the incoming message shall be mapped to different interfaces and go to different receivers dependent on the payload content. If no condition can be evaluated to true, an error message shall be generated. The first condition for the receiver REC_1_PRD looks like the following:

Figure 8: First condition in the integration flow

To cover all possible paths, I will need three different test message exchange drafts to test the first condition. Two message exchange drafts are for both ‘OR’ parts of the condition, which I expect to be processed successfully. The third message exchange draft does not match the condition and therefore shall result in an error.

I create additional message exchange drafts by copying my first message exchange draft (Add Message Exchange Draft -> New By Copy) and modify content of all three drafts according to my condition. I rename each message exchange draft, so that I can easier recognize which message covers which constellation.

Figure 9: Three message exchange drafts to cover the condition

Remember, as my dummy integration flow has no condition yet (see figure 1) all three message exchange drafts will succeed, when processing right away. However, this is not what I want to achieve.

Therefore, I go back to Integration Designer and modify my integration flow. I remove the dummy receiver, instead message shall go to the receiver REC_1_PRD. And I maintain the condition mentioned in the figure 8. In case no condition can be evaluated to true, message shall fail with error. I activate and deploy the changed integration flow.

Figure 10: First condition + receiver in the integration flow

Back in the Process Integration Test perspective, I process the three messages, which I prepared in the step before and get the result shown in figure 11. As expected, two messages are processed successfully and the third message fails with an error, as no receiver was found.

Figure 11: Messages for the first receiver after processing

Create a Test Data Set

As next, I’m going to create two new test datasets ‘Path to PRD1 – success’ (containing successful messages) and ‘Path to PRD1 – error’ (containing error messages) for the first receiver REC_1_PRD using my messages. I decided to create two test datasets with only successful and only erroneous messages instead of one mixed test dataset (which is also possible), because later I would like to run a positive and a negative test.

I select the desired messages in status ‘Processed’ (hold Ctrl-key while selecting messages for multiple selection) and choose  “Create new test dataset”.

Figure 12: Create a new test dataset

The test datasets are added to the test case and can be used in run configurations.

Figure 13: Two test datasets created from test data workbench

Test Case Run Configuration

To be able to run a test in PIT, I need a run configuration. I create two run configurations – one for positive test and one for negative test using the above test data sets. In the negative test I would like not only to check, that the message fails but also that the message fails in the ROUTING step (‘Verify Error Expectation’ is checked).

Figure 14: Create run configurations, which use previously created test datasets

I execute my run configurations and expect, that their execution will be successful. However, the first run for “Receiver PRD OK” fails due to differences in fields Id and employedSince, whose content is generated by mapping and will always differ between the runs. So, I must add exemptions to get the scenario successfully running.

Figure 15: Scenario requires exemption before being successful (exemption for Id already defined)

I use the “Add Verification Exemption” wizard, which helps me to add a new exemption easily. It suggests me an XPath to be added based on the verification results. I finish the wizard and save the test case with the added exemption.

Figure 16: ‘Add Verification Exemption’ wizard

With the exemption, the positive test can be executed successfully.

Figure 17: Successful execution of positive test after adding exemption and successful negative test

Also, my negative test succeeds with the expected result (means, it fails with in error in ‘Routing’ step) as visible in the figure 17.

These run configurations can be executed after each iteration in the development process, e. g. when a new condition or a new receiver is added. But I can additionally collect all run configurations into one test suite and execute them comfortably on a scheduled base.

Test Suite

I create a new test suite and assign my test case to it. Test suites are visible in the Test Catalog, if ‘Test Suite’ is selected as top-level element.

Figure 18: New test suite

As for test cases, PIT requires a ‘Test Suite Run Configuration’ as executable entity. It contains a set of test case run configurations. I assign my two available run configurations to the test suite run configuration.

Figure 19: Test suite run configuration as executable entity

Now, I can schedule my test suite run configuration for regular, e. g. daily execution. This will allow me a continuous monitoring of my development process and ensure that my changes do not have any side effects, which unintentionally damage other conditions. I also assign an alert configuration to the scheduled task, so that I’m notified in case of failures and thereby don’t need to check each execution manually.

Figure 20: Create scheduled task for daily execution

The scheduled task is visible in the ‘Scheduled Tasks’ view (Window -> Show View -> Scheduled Tasks). From this view I can jump to the Action Log and display all its executions at one glance (context menu ‘Show Action Log’) as shown in Figure 21.

Figure 21: Scheduled task view

Luckily, my test runs still successfully also as a scheduled test suite run.

Figure 22: Action Log showing all executions of the scheduled task

Thus, I can continue with my development and add more receiver, each with own condition. If I repeat below steps for each receiver and each condition, I will over time collect a nice list of suitable run configurations for each possible path. Executed after each iteration or on regular basis, it will allow me to recognize errors quickly, give me the confidence that the scenario is configured correctly and improve the quality.

Summary

In this blog post I described step by step how you can improve the development process of your PI scenario (using the example of Integration Flow development) using majority of the features available in SAP Process Integration Test. This procedure will help you to go one step towards test-driven development, to achieve high test coverage and to improve the quality of your develoment process.

Find more about PIT in SAP Help Portal and our blog posts in the “PIT – What’s new” series.