Creating Test Cases

The source system is the reference system within a process integration test. It defines the correct and expected behavior of integration scenarios selected for testing. Message exchanges extracted from the source system are considered to be the expected message processing results.

• Information on configuration objects available in the Integration Directory (Integrated Configuration, Integration Flow, or Receiver Determination).
• Successfully processed Process Integration messages including their payload. These messages are later used as reference data for the test (Test Data Set).

The target test system is the system under test. To test integration scenarios on a target system, test messages are injected, and the message processing results are compared with the corresponding data from the source system. On the target system, the messages are processed by the standard pipeline of the Adapter Engine. The results of the execution are fetched by PIT subsequently.

You assign configuration objects to your test case. A configuration object describes how the message flow is configured in the corresponding source or target system. It’s either an instance of an integrated configuration, an integration flow, or a receiver determination.

Typically, several configuration objects are assigned to a test case. Ideally, one test case contains one configuration object per test system participating in the test. Ensure that configuration objects assigned to one test case describe the same message flow, otherwise your test data could be useless or the test not operable.

Nevertheless, the same message flow can be configured differently in different systems. In a Process Integration dual stack/dual usage type system, the message flow is configured to go through the Integration Engine. It’s, therefore, described by loosely coupled configuration objects: a sender agreement, a receiver determination, an interface determination, and a receiver agreement. In an AEX system, the same message flow is configured as an integration flow or by using an integrated configuration object. The configuration can also be slightly different in each system, for example by using a different mapping.

The PIT configuration object only contains a reduced set of data from the original Integration Directory object: the header information, the sender and receiver configuration. It also contains some attributes from the communication channel, such as the Adapter Engine used.

A test data set contains messages extracted from an SAP Process Integration system, and is used as reference data during test execution.

The PIT tool extracts the original message exchange with the inbound payload as well as the versions before and after mapping, from the source system. In case of synchronous communication, the same payload versions for the response are extracted as well.

A test data set can contain many messages, and a test case can contain many data sets that were extracted at a different point in time.

The PIT tool supports extraction of successfully processed messages only. But a log version of a message before and after a potential mapping must exist. Therefore, you have to enable message logging before starting message processing.

Message preprocessing allows you to replace values in the payload or values of dynamic headers on the fly before the message is sent to the target system. The replacement can be valid for all system combinations or only for one specific system.

There are scenarios, where, for example, in addition to the message header, the name of a sender system is contained in the payload or in a dynamic header. PIT sets the message header automatically according to the configuration scenario. But values in the payload or dynamic header can’t be adjusted automatically. They are still equal to values in the source payload. If a particular dynamic header or XML node is used in a routing condition in the target system, the routing can fail or lead to a wrong result because of the unexpected value. This makes it impossible to test successfully.

Another use case for modifying the payload on the fly is if you want to test all possible routing paths in the target system, but it is very hard to create a test data set for each of the paths. You can artificially replace a value in the message to test each possible condition path using message preprocessing (assuming that the rest of the payload is valid as well).

Preprocessing Ruleset: Message preprocessing can be defined as part of a test case. You have to create a preprocessing ruleset to define substitution rules to apply to the message. A test case can contain many preprocessing rulesets. In the run configuration you can decide which preprocessing ruleset should be used at runtime. Only one preprocessing ruleset can be used per run

Preprocessing Rule: Each preprocessing ruleset contains at least one preprocessing rule. The rule is applicable to a specified area – currently you can choose between payload or dynamic header. It contains at least one preprocessing instruction with a specified substitution flavor (defined by substitution type):

• Constant value substitution:

  Allows you to replace a value independently of the source and target system combination.

  Xpath	Source Value	Target Value
  /Address/Street	Maple Street	Apple Street
  /Address/Name	Ellen Adams	Ellen Jones

• System-dependent value substitution:

  Allows you to replace a value dependent on target system (or even based on source/target system combination).

  Xpath	Source System	Source Value	Target System	Target Value
  /Address	DEV	Maple Street	QUE	Apple Street
  	DEV	Maple Street	TST	Oak Street

• Replacement Rule:

  Substitution using a Replacement Rule can be regarded as a special case of a system-dependent value substitution.

  
  The figure PIT Add Rule shows an example of the Rule.

  Preprocessing Instructions

  Each preprocessing instrustion must contain either:

  • a valid Xpath expression that points to an XML node in the payload (for area = "Payload")
  • or name and namespace of a dynamic header (for area = "Dynamic Header")

During the creation phase, you can select one of the available Extraction Types and, if needed, configure the extraction schedule:

• Immediate one-time extraction: the extraction takes place once and as soon as you select Finish.
• One-time extraction at scheduled date: the extraction takes place once and at a time and date you specify.
• Periodic extraction at scheduled date (produces multiple test datasets): the extraction takes place at a time and date you specify (Start), recurs at defined intervals (Recurrence), and stops at defined point in time (End).

To work with the periodic extractions, use the Periodic Extraction Editor. The editor provides read-only information about a periodic extraction and its extracted test datasets.

The graphical message exchange structure reflects the processing steps in the XI pipeline. It contains the following elements:

• The circles at the beginning and the end of the graphic represent sender and receivers of the message.
• The rectangles represent the available message versions: the incoming message (BI version), and the outgoing messages (MS and AM version). Select the corresponding rectangle in the Properties view, to display the message header, dynamic header, payload, or attachment information for the message version.
• Hexagons represent the processing steps of the XI pipeline, such as routing, mapping, receiver delivery, and response correlation (for synchronous exchanges only). Two or more outgoing connections denote a message split. If the processing of a step encounters an error, the element is highlighted with a red border and an exclamation mark icon. Select the element to see details about the error category and error code in the Properties view.
• In a synchronous message exchange, a dashed line from the sender to the receiver (and the steps in between) represents the response processing path.

If you open the Message Structure Viewer from the Test Dataset editor, it only shows the structure of the selected message. If you open it from the result overview, you see the structure of the source and the target message one below the other, assuming that both structures are available.

A retention policy defines how long you keep data before it may be deleted automatically. Once the retention time expires, the data will be deleted by the deletion job. This way you can automatically delete data before they accumulate in the database, but at the same time you can mark important data as not needing to be deleted at all. A retention policy considers data that was generated during executions of Test Case Run Configurations and Test Suite Run Configurations, which you can see in the Job Browser and Action Log views.

Unless a different retention policy is created and assigned, the Default Policy is assigned to your job data and target messages. If the administrator hasn't done any changes to the default policy in their system, the default retention policy retains the data for an unlimited time frame unless it's deleted manually.

To view existing retention policies, in SAP NWDS go to Process Integration → Retention Policies Overview, or go to Window → Show View → Retention Policies View.

As a prerequisite for data to be deleted in accordance with a retention policy, your administrator must plan the background job PITDeletionJob regularly to execute the deletion. This job checks if retention time did run out for any data and deletes it. If no deletion job is planned, no data is deleted, even if the retention time has run out.

You can schedule PITDeletionJob at NetWeaver Administrator → Operations → Jobs → Java Scheduler → Tasks.

If the background deletion job might not delete the data, you can still delete the data manually.

You can protect results against deletion. If a job is protected, it may never be deleted automatically by the deletion job, even if the retention time has already expired according to the retention policy. It can only be deleted, either automatically or manually, once the protection is removed.

• Adapter modules processing isn’t part of the test.
• Business Process Management (BPM) is out of scope.
• The PIT tool isn’t suitable to be used as load generator (to run performance tests)
• The PIT tool must not be used to read, store, or process messages containing personal sensitive data.

• Data extraction of unsuccessful messages.
• Scenarios using integrated configuration or integration flow with sender or receiver wild card.
• Scenarios with sync/async bridge and async/sync bridge.