- SAP Managed Tags:
This is the second 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 which also provides you the context of this best practices series.
In the current blog, I would like to describe the PIT setup for a use case based on dynamic headers.
A message is exchanged between a sender system and multiple receiver systems. The routing rule is based on a dynamic header service which is provided by the client application calling the integration flow end point. To keep it simple, the dynamic header contains the name of the receiver system. The integration flow pattern is of type arbitrary receiver, i.e., we use receiver wildcards.
For each potential receiver, a receiver agreement is maintained as you can see from the list of possible receiver agreements.
Note, sender and receiver names differ depending on the respective landscape, on the test landscape the sender name is SND_C_TST, and the receiver systems are REC_1_TST, REC_2_TST, and REC_3_TST, respectively. On the productive landscape the corresponding systems are SND_C_PRD, REC_1_PRD, REC_2_PRD, and REC_3_PRD, respectively.
The intention of the integration test is mainly to verify that messages are properly routed to the right receiver system. Since the system names differ across the different landscape as described above, this requires a specific test setup.
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. As you can see in the test dataset editor, the dynamic header field service holds the name of the receiver system. Since the data is pulled from the production system, the name refers to the production landscape.
As described in the previous blog, 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 done on the Verification tab of the test case. We select the StructureComparator verification step, and maintain the rules accordingly.
Whereas the headers are automatically set according to the integration flow configuration of the specific landscape when running the tests, this is not the case for the dynamic headers. To avoid a receiver not found error, we need to define a preprocessing rule to change the service name on the test landscape, e.g., from REC_1_PRD to REC_1_TST. On tab Message Preprocessing, we create a new ruleset with a rule of area Dynamic Header and type Constant Value Substitution. For each receiver, we define the service name and the corresponding matching source and target values.
Since we have changed the name of the dynamic header field applying the preprocessing rule, we need to exclude the dynamic header field from the comparison. Otherwise, this would result in a deviation during verification. We switch back to the Verification tab, select the HeaderComparator verification step, and maintain the exemption rule accordingly. So, type of the exemption is Header Element, and name of the header element is service with appropriate namespace of the dynamic header property.
To directly run or schedule the test run, we define a run configuration where we maintain the test case, the test data set, the target system, and the beforehand created preprocessing rule.
After having executed the test run and verification job, the test case verification result shows no verification differences.
If I select one of the successfully processed messages within the test case verification result, I can verify that the messages have been routed properly. As you can see from the message header of the outgoing message exchange, the message is routed to the receiver system REC_1_TST which matches with REC_1_PRD on the production landscape.
When selecting the Dynamic Header node of the outgoing message exchange, the dynamic header service between the target and the source differs however an information is displayed in the Test Verifications Problems tab indicating that for this header field an exemption exists.
With this you have seen how to alter a dynamic header applying a preprocessing rule. In the next blog, I will describe the PIT setup for a content based routing scenario.
If you haven't read so far, please also check out the first blog which also provides you the context of this best practices series.
In the current blog, I would like to describe the PIT setup for a use case based on dynamic headers.
Use case
A message is exchanged between a sender system and multiple receiver systems. The routing rule is based on a dynamic header service which is provided by the client application calling the integration flow end point. To keep it simple, the dynamic header contains the name of the receiver system. The integration flow pattern is of type arbitrary receiver, i.e., we use receiver wildcards.
For each potential receiver, a receiver agreement is maintained as you can see from the list of possible receiver agreements.
Note, sender and receiver names differ depending on the respective landscape, on the test landscape the sender name is SND_C_TST, and the receiver systems are REC_1_TST, REC_2_TST, and REC_3_TST, respectively. On the productive landscape the corresponding systems are SND_C_PRD, REC_1_PRD, REC_2_PRD, and REC_3_PRD, respectively.
Test case
The intention of the integration test is mainly to verify that messages are properly routed to the right receiver system. Since the system names differ across the different landscape as described above, this requires a specific test setup.
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. As you can see in the test dataset editor, the dynamic header field service holds the name of the receiver system. Since the data is pulled from the production system, the name refers to the production landscape.
As described in the previous blog, 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 done on the Verification tab of the test case. We select the StructureComparator verification step, and maintain the rules accordingly.
Whereas the headers are automatically set according to the integration flow configuration of the specific landscape when running the tests, this is not the case for the dynamic headers. To avoid a receiver not found error, we need to define a preprocessing rule to change the service name on the test landscape, e.g., from REC_1_PRD to REC_1_TST. On tab Message Preprocessing, we create a new ruleset with a rule of area Dynamic Header and type Constant Value Substitution. For each receiver, we define the service name and the corresponding matching source and target values.
Since we have changed the name of the dynamic header field applying the preprocessing rule, we need to exclude the dynamic header field from the comparison. Otherwise, this would result in a deviation during verification. We switch back to the Verification tab, select the HeaderComparator verification step, and maintain the exemption rule accordingly. So, type of the exemption is Header Element, and name of the header element is service with appropriate namespace of the dynamic header property.
To directly run or schedule the test run, we define a run configuration where we maintain the test case, the test data set, the target system, and the beforehand created preprocessing rule.
After having executed the test run and verification job, the test case verification result shows no verification differences.
If I select one of the successfully processed messages within the test case verification result, I can verify that the messages have been routed properly. As you can see from the message header of the outgoing message exchange, the message is routed to the receiver system REC_1_TST which matches with REC_1_PRD on the production landscape.
When selecting the Dynamic Header node of the outgoing message exchange, the dynamic header service between the target and the source differs however an information is displayed in the Test Verifications Problems tab indicating that for this header field an exemption exists.
With this you have seen how to alter a dynamic header applying a preprocessing rule. In the next blog, I will describe the PIT setup for a content based routing scenario.
