- SAP Managed Tags:
This is the third blog in the blog series about best practices for using replacement rules and preprocessing rules within the Process Integration Test (PIT) tool of SAP Process Orchestration.
If you haven’t read so far, please also check out the first blog describing a value mapping use case and also providing you the context of this best practices series.
In the second blog, I cover PIT for a dynamic header use case.
In the current blog, I would like to describe the PIT setup for a content based routing use case.
HR data of employees and candidates should be replicated between different systems. In total, we have four receiver systems. Depending on different attributes, the data is either routed to system REC_1_PRD holding employee data, system REC_2_PRD holding candidate information, or system REC_3_PRD keeping former employee data. Each receiving system has its own interface defined and hence each route runs a different mapping.
As you can see from the static routing conditions below, system REC_4_PRD is defined as default route. If no other condition is met, messages are routed to the default. This is actually the case if the data is inconsistent.
Besides checking if the different mappings run properly, we also like to verify that the conditions are properly carried out, i.e., that the messages are routed to the correct receiver.
In the PIT tool, we create the following test case with the production system A8Z as source system where the test data is pulled from, and N75 as target system where the test runs are carried out.
We have uploaded test messages from the production system which covers different situations. In the Test Dataset Editor, you can see how such an input message may look like. The example below shows a candidate which was previously employed at the company whereas the new hiring process has been completed. In this case, the terminated field must be n/a.
If you select the Message Header of the outgoing message, you can see that this candidate is routed to the first receiver system REC_1_PRD and mapped to the employee service interface.
As you can see from the outgoing payload, in the mapping an employee identifier and the date of employment are automatically generated besides other field mappings.
The integration flow on the test system differs from the flow as described above in the sense that the connected systems all end with TST instead of PRD. So, we need to define replacement rules for the system headers to match the systems of the production landscape to the corresponding systems of the test landscape. This is also described in the previous blogs, see here for instance.
For IDs and time stamps, i.e., fields that we know will change in any case when rerunning the tests, we need to define exemptions. This is not shown here since I already covered this in the previous blogs.
After having executed the test run and verification job, we can check the test case verification results. As you can see from the Message Header of the outgoing message, the message is routed to the correct receiver.
In the following, we would like to intensively test the conditions in case of faulty data, i.e., if the data is inconsistent as such. In this case, the message should be routed to the default receiver system.
We created a new test case where we uploaded a sample message with inconsistent content. In the example below, the hiringCompleted and the terminated fields are both true which is a contradiction.
Other faulty messages are not available, so we use message preprocessing to extend the test coverage. On tab Message Preprocessing, we create different rulesets each having one rule for altering the payload. The rules are of area Payload and substitution type Constant Value Substitution. For each rule, we overwrite the corresponding payload fields with a value combination that leads to inconsistencies and hence simulates different default route situations.
In the example below for instance, the candidate hasn't been employed at the company before and hence the okToRehire field must be actually n/a, here however it's true.
Since we changed the various fields of the incoming message in the message preprocessing, the corresponding fields of the outgoing message will definitely differ from the expected values of the stored test message. So, we need to define exemption rules for all fields that were overwritten in the message preprocessing. On the Verification tab of the test case, we select the PayloadComparator verification step, and maintain the corresponding xpath expressions.
For each field combination that we have defined in the message preprocessing, we define an own run configuration where we maintain the test case, the test data set, the target system, and the corresponding preprocessing ruleset. In total we have five run configurations. By the way, the first run configuration processes the original data and hence doesn't need a message preprocessing ruleset.
In order to run all run configurations at once, we define a test suite and a test suite run configuration, latter containing all beforehand created run configurations.
The test suite run configuration can be scheduled. In our case, we ran only once. Usually, you would schedule the tests to run on a regular basis.
In the action log, I can see the overall results of the test runs and the verifications. As you can see, the tests were successfully carried out without any regressions.
I I open one of the verification results, I can see that the message has been routed to the REC_4_TST system which is the default route and which matches the system REC_4_PRD on the production landscape.
If I switch to the Payload node of the outgoing message, the expected differences between the source and the target are highlighted. However, since we defined exemptions for those fields, we just get informed about existing exemptions.
As an alternative to the PIT tool user interface in the SAP NetWeaver Developer Studio, test suites can be scheduled and monitored within a web-based interface using SAP UI5 technology as well. So, you see the very same test execution results in the web UI. For more details about the web-based user interface, check out Working with the SAP PIT Tool Using Web-Based User Interface.
Hope this blog and the other two blogs helped you to better understand the ways replacement rules and preprocessing rules can be used within your test cases.
If you haven’t read so far, please also check out the first blog describing a value mapping use case and also providing you the context of this best practices series.
In the second blog, I cover PIT for a dynamic header use case.
In the current blog, I would like to describe the PIT setup for a content based routing use case.
Use case
HR data of employees and candidates should be replicated between different systems. In total, we have four receiver systems. Depending on different attributes, the data is either routed to system REC_1_PRD holding employee data, system REC_2_PRD holding candidate information, or system REC_3_PRD keeping former employee data. Each receiving system has its own interface defined and hence each route runs a different mapping.
As you can see from the static routing conditions below, system REC_4_PRD is defined as default route. If no other condition is met, messages are routed to the default. This is actually the case if the data is inconsistent.
Basic test case
Besides checking if the different mappings run properly, we also like to verify that the conditions are properly carried out, i.e., that the messages are routed to the correct receiver.
In the PIT tool, we create the following test case with the production system A8Z as source system where the test data is pulled from, and N75 as target system where the test runs are carried out.
We have uploaded test messages from the production system which covers different situations. In the Test Dataset Editor, you can see how such an input message may look like. The example below shows a candidate which was previously employed at the company whereas the new hiring process has been completed. In this case, the terminated field must be n/a.
If you select the Message Header of the outgoing message, you can see that this candidate is routed to the first receiver system REC_1_PRD and mapped to the employee service interface.
As you can see from the outgoing payload, in the mapping an employee identifier and the date of employment are automatically generated besides other field mappings.
The integration flow on the test system differs from the flow as described above in the sense that the connected systems all end with TST instead of PRD. So, we need to define replacement rules for the system headers to match the systems of the production landscape to the corresponding systems of the test landscape. This is also described in the previous blogs, see here for instance.
For IDs and time stamps, i.e., fields that we know will change in any case when rerunning the tests, we need to define exemptions. This is not shown here since I already covered this in the previous blogs.
After having executed the test run and verification job, we can check the test case verification results. As you can see from the Message Header of the outgoing message, the message is routed to the correct receiver.
Testing the default route
In the following, we would like to intensively test the conditions in case of faulty data, i.e., if the data is inconsistent as such. In this case, the message should be routed to the default receiver system.
We created a new test case where we uploaded a sample message with inconsistent content. In the example below, the hiringCompleted and the terminated fields are both true which is a contradiction.
Other faulty messages are not available, so we use message preprocessing to extend the test coverage. On tab Message Preprocessing, we create different rulesets each having one rule for altering the payload. The rules are of area Payload and substitution type Constant Value Substitution. For each rule, we overwrite the corresponding payload fields with a value combination that leads to inconsistencies and hence simulates different default route situations.
In the example below for instance, the candidate hasn't been employed at the company before and hence the okToRehire field must be actually n/a, here however it's true.
Since we changed the various fields of the incoming message in the message preprocessing, the corresponding fields of the outgoing message will definitely differ from the expected values of the stored test message. So, we need to define exemption rules for all fields that were overwritten in the message preprocessing. On the Verification tab of the test case, we select the PayloadComparator verification step, and maintain the corresponding xpath expressions.
For each field combination that we have defined in the message preprocessing, we define an own run configuration where we maintain the test case, the test data set, the target system, and the corresponding preprocessing ruleset. In total we have five run configurations. By the way, the first run configuration processes the original data and hence doesn't need a message preprocessing ruleset.
In order to run all run configurations at once, we define a test suite and a test suite run configuration, latter containing all beforehand created run configurations.
The test suite run configuration can be scheduled. In our case, we ran only once. Usually, you would schedule the tests to run on a regular basis.
In the action log, I can see the overall results of the test runs and the verifications. As you can see, the tests were successfully carried out without any regressions.
I I open one of the verification results, I can see that the message has been routed to the REC_4_TST system which is the default route and which matches the system REC_4_PRD on the production landscape.
If I switch to the Payload node of the outgoing message, the expected differences between the source and the target are highlighted. However, since we defined exemptions for those fields, we just get informed about existing exemptions.
As an alternative to the PIT tool user interface in the SAP NetWeaver Developer Studio, test suites can be scheduled and monitored within a web-based interface using SAP UI5 technology as well. So, you see the very same test execution results in the web UI. For more details about the web-based user interface, check out Working with the SAP PIT Tool Using Web-Based User Interface.
Hope this blog and the other two blogs helped you to better understand the ways replacement rules and preprocessing rules can be used within your test cases.
