With SP 26, PIT offers a new feature ‘Test Data Draft Workbench’, which targets those scenarios where you need to compile a test dataset with custom message exchanges, which do not exist in your system. In the nutshell, in the test data draft workbench you can add one or many initial message exchanges (for example from scratch or from an existing test dataset), you can modify these message exchanges to your needs and afterwards process them through the PI pipeline to get a complete and valid PIT message exchange, which includes incoming and outgoing message version. Finally, you can create a new test dataset containing processed message exchanges and use it in your tests.

In this blog post, I would like to elaborate on the main features of the test data draft workbench and show you how you can work with it.

Idea Behind Test Data Draft Workbench

In the test data draft workbench you work with test data drafts. A test data draft is an entity, which is introduced with SP 26 in Process Integration Test. The basic idea behind a test data draft is, that you have the freedom to compile the inbound version of your own message exchanges. You can take an existing message exchange as a template and modify it, or you can create your message exchange completely from scratch. In the next step, this message exchange is processed by the PI pipeline to get a complete and valid message exchange with incoming (Before Mapping) and outgoing (After Mapping) version. Once you are satisfied with the results, you can create a test dataset with this data, assign it to a test case and use in your test case run configurations.

Test Data Draft Overview

When you’re in the NWDS perspective SAP Process Integration Test, navigate to the menu and select Process Integration -> Test Data Draft Overview (or menu Window -> Show View -> Test Data Draft Overview) to show the Test Data Draft Overview. In this view you can create new and manage existing test data drafts. A test data draft has a special characteristic, that it always belongs to a user and can be displayed and edited only by this user.

Create a new test data draft and assign the configuration object – an integrated configuration or an integration flow – to it. The configuration object will be used later as the underlying scenario for the processing in the PI pipeline.

Figure 1: ‘Create Test Data Draft’ wizard

Test Data Draft Workbench

The new test data draft opens automatically in the Test Data Draft Workbench. At the top of the editor, there is a summary of general data like name and description, assigned configuration object and the communication pattern. Contrary to test case editor, you can change the communication pattern in the test data draft workbench.

Message exchange draft list contains one or many message exchange drafts. Each message exchange draft has at least an initial message exchange, which represents the incoming version (BI-version). When you select a message exchange draft from the list, its structure is shown in the tab below the list in a tree-like representation. The content of the selected message exchange tree node (dynamic header, payload, attachment, mock response) is shown in the content area on the right side.

Figure 2: Test data draft workbench’s areas

Each message exchange draft has a status. The status transition is well-defined, and some operations are available only in certain states.

Add New Message Exchange Draft

Add a first message exchange draft from scratch using Add Message Exchange Draft -> Create New as shown in figure 3 below. You need to define the content type of the initial request payload (xml or text) and its payload content. If the underlying scenario refers to a service interface, which is modeled in the ESR, the dialog can generate a payload stub for you. Just select corresponding root element from the combo box. In the create dialog, only elements with occurrence > 0 will be generated. However, in the XML editor you can later add also optional elements.

You can optionally give message exchange draft a name. If no name is entered, a generated GUID is used as name. Message exchange draft can be renamed later; double click on the GUID in the message exchange draft list or use ‘Rename’ from context menu. You can use the name to highlight certain message exchanges or note down its purpose for yourself (e. g. if this exchange tests a certain condition, the name could indicate the condition).

Figure 3: ‘New Message Exchange Draft’ dialog

Once the dialog is confirmed, the new message exchange draft appears in the message exchange draft list. Right after creation, the message exchange draft has the Status ‘New’ and consists only of the initial message exchange.

Figure 4: Message exchange draft in status ‘New’ in the test data draft workbench

Besides of creating a message exchange draft from scratch, you can also add them from an existing test dataset, from a PIT export file or by copying another message in your test data draft workbench. In all these cases, only the initial message exchange is taken over from the original. If the communication pattern of the test data draft is set to synchronous and your original test dataset is also synchronous, request and response of the incoming message are taken over. Otherwise only the request part is transferred.

Process Message Exchange Draft Through PI Pipeline

In the next step, process the message exchange draft through the pipeline in order to generate a message exchange with incoming and outgoing message. You can select one or many messages (hold the Ctrl-key and select rows with the mouse or keyboard for multiple selection) and choose ‘Process selected messages’. You can decide, if messages shall be sent to the receiver or stopped right before handing over to receiver (choose the option ‘Send to Receiver’ or ‘Skip Receiver’ from the drop-down). In the synchronous case make sure, that you send the message to receiver to get a valid response, or your initial message exchange contains a mock response, which can be used by the PI pipeline.

During processing, the message exchange will be injected after the sender adapter and sender module chain into the PI message pipeline in the selected test system (test system of the configuration object), as you know it from the regular PIT execution. Afterwards it passes through the PI pipeline according to the configured scenario and receiver handling option. The processing results are collected and stored in PIT. While a message is processing, its status changes to ‘Processing’. Usually, this status is visible only for a very short time and changes then to ‘Processed’ or ‘Failed’.

If the message exchange is processed successfully through the PI message pipeline, the status of message exchange draft becomes ‘Processed (Successful Exchange)’. A second tab ‘Processed Message Exchange’ shows up in the message exchange tree area. It contains a complete, valid message exchange, which can be used in positive PIT test cases.

If there was any regular error during processing (e. g. mapping failed, receiver not found) the status becomes ‘Processed (Failed Exchange)’. The tab ‘Processed Message Exchange’ contains a potentially incomplete, but nevertheless valid PIT message exchange as well as error step and error message. Such message exchanges can be used for negative PIT test cases.

Figure 5: Successfully processed message exchange draft

You can display the structure of ‘Processed’ message exchange also in graphical way using “Show message structure” from the toolbar or from context menu.

Figure 6: Graphical view of the ‘Processed’ message exchange

A message exchange can also result in state ‘Failed’, if no meaningful message exchange can be created or there is a technical error. Some typical examples are: logging is not enabled for a configuration scenario and therefore a message exchange can’t be extracted by PIT; a synchronous message exchange should be processed using ‘Skip receiver’, but there is no mock response available. For a message exchange draft in status ‘Failed’ there is tab ‘Processing Error’, where the error details are displayed. There is no valid message exchange available in this case.

Figure 7: Example of a ‘Failed’ message exchange draft

Edit Message Exchange

The initial message exchange can be edited any time if the test data draft workbench is in the ‘Edit’ mode. Toggle button   ‘Enable Editing’ from the toolbar or from context menu to enable or to disable editing mode. The message exchange tree area and content area visualize editing mode with a red border. Only the initial message exchange can be edited. The processed message exchange is always generated by the system and is therefore read-only (therefore the editing mode button is disabled if a processed message exchange is selected).

Figure 8: Test data draft workbench with enabled editing mode

In the editing mode you can make changes to the content and structure of the initial message exchange – edit payload; edit, add and remove dynamic headers; edit, add and remove attachments; additionally in synchronous case: edit, add and remove mock response.

An edited message exchange draft is not immediately stored on the server. It is marked with a red checkmark  in the Changed column of the message exchange drafts list. Additionally, each changed section is marked with the red checkmark in the message exchange tree. The buttons  ‘Save’ and  ‘Revert’ become enabled.

While a newly created message exchange draft is automatically stored right after adding it, the changes to the message structure or its content must be explicitly stored using the ‘Save’ button. There are three ‘Save’ buttons with slightly different context available:

1. ‘Save’ button in the content area’s toolbar stores only changes in currently visible section. Section means in this context – payload, dynamic header, attachments (all attachments, not only the selected one) or mock response. In case any other section contains changes as well, those changes will not be stored.
2. ‘Save’ button above message exchange draft list stores changes in all changed sections of the selected message exchange draft.
3. ‘Save’ button in the main eclipse toolbar saves changes in all sections of all message exchange drafts in the current test data draft.

Saving a message exchange draft changes its status to ‘Edited’. If a message exchange draft was in status ‘Processed’ before editing, the processed message exchange will be invalidated and disappears. You will need to process the message exchange draft again with the updated content. Keep in mind that processing is always done using the version of the message, which is available on the server. Any not-yet-stored changes will be ignored during processing.

Figure 9: Message exchange draft with edited payload

You can also decide to revert changes using  ‘Revert’ button:

– ‘Revert’ button above content area reverts only changes in the currently visible section.

– ‘Revert’ button above message exchange draft list reverts changes in all sections of the selected message exchange draft.

The status of the message exchange draft stays unchanged in case of ‘Revert’.

Edit XML Payload Content

Select the structure node Payload in the initial message exchange tree to load the content. In edit mode the payload editor in the content area is editable and allows you to change the content. For payloads of type XML, the XML editor offers a reach feature set:

Syntax Highlighting

The editor uses the same syntax highlighting preferences as the existing viewers in the test dataset editor and verification difference view. You can configure your preferred style via preference page XML -> XML Files -> Editor -> Syntax Coloring.

Content Formatting

You can apply a default indentation and whitespace format by selecting the corresponding context menu function or with the standard “Ctrl-Shift-F” key binding. You can specify your preferred indentation character (space or tab) and indentation width with the preference page under XML -> XML Files -> Editor.

Auto Complete

In certain situations, the XML editor can automatically complete a user input and append required and useful data. Example: if a user opens a tag with the character ‘<’, the editor can automatically supply the closing ‘>’. This can also be enabled for brackets, single/double quotes, comment delimiters and even complete closing tags. The auto-complete behavior is configurable with the preference page under XML -> XML Files -> Editor -> Typing. It’s definitely worth checking this page as many options might be disabled by default.

Content Assist

By far the most ambitious and complex feature of the XML editor is the XML schema based content assist functionality. Content assist is started with the standard key binding “Ctrl + Space” and tries to compute reasonable content proposals for the current cursor position in the editor. In case that the test data draft’s integrated configuration or integration flow refers to a service interface which is defined for a software component version in the ESR, the editor tries to retrieve the corresponding XML schema and uses it for proposing suitable XML elements, simple content values, attribute values and attribute names. In ideal cases, this mechanism can vastly reduce the complexity of XML content creation to the point where it rather feels like filling a form.

Please note that this feature uses fixed namespace prefixes ns0, ns1, etc. for all namespaces of the main XSD and imported ones and strongly depends on these prefixes and their order to properly resolve XML elements and attributes. Therefore, it is recommended to take over the proposed XML content in the “Add new message exchange draft” wizard or to create the root element using content assist and to keep the namespace declarations.

XML and Schema Validation

You can validate XML content by selecting the corresponding context menu function or with key binding “Ctrl + F7”. The editor tries to visualize the error location as precise as possible.

Figure 10: Content assist example using Ctrl+Space

Figure 11: XML validation against XSD schema example

Of course, you can also edit payloads with content type ‘Text’, however without any assistance of the editor. The content of a binary payload can’t be shown in the editor, but it is possible to replace existing content with another file. Please keep in mind, that the content type of the payload can’t be changed, only the content itself.

Working with Dynamic Headers

Select the structure node Dynamic Header in the message exchange tree of the initial message exchange. In the table you can edit header value, its name and namespace, add new headers, or remove existing headers. It is not allowed to have a header entry with empty name or duplicates with identical values.

Figure 12: Edit dynamic header

Working with Attachments

If your message has an attachment, it is shown as own node in the message exchange tree. Select the corresponding structure node to show attachment content in the content area. There are the same editor functionalities available for attachments as for payloads (except the XML schema based assistance tools for XML content). All attachments build one logical section. This means for Save and Revert, that if many attachments are changed all of them will be stored / reverted.

Add a new attachment by selecting the structure node with the message-id or its child nodes and choose  ‘Add Attachment’ from the toolbar or context menu. In the dialog that appears, provide the name of the attachment, its content type and the content itself. After the dialog is confirmed, the new attachment node will be added to the message exchange tree and is marked with a  decoration.

Figure 13: Add attachment to message exchange draft

If you want to remove an attachment, select the corresponding attachment node and choose “Delete Attachment”. The attachment is marked with a  overlay. The attachment will be actually deleted once the message exchange is saved.

Don’t forget to save the section or the whole message exchange draft to take over the changes.

Working with Mock Response

In case your scenario is synchronous and communication pattern is set correspondingly, you can model a mock response. A mock response will be used during processing, if your message shall not be processed by a real receiver (that means you process with “Skip Receiver”).

A mock response can be taken over automatically when adding a message exchange draft from a test dataset or from file. Prerequisite is that communication pattern is set to ‘Synchronous’ and the test data source contains a synchronous message exchange as well.

But you can also add a mock response manually. In the message exchange tree, select the structure node with the message-id (or its child nodes) and choose “Add Mock Response” from the toolbar or context menu. Choose a content type and fill the response content, confirm with “Finish”. A new structure node Mock Response will be added to the message exchange tree and marked with a decoration.

Don’t forget to save the message exchange draft to apply your changes on the server.

Figure 14: Add mock response to message exchange draft

You can edit the mock response payload the same way as the request payload, using all available editor features (except the XML schema based assistance tools). However, handling of dynamic headers in the response is not available, as this feature is not supported by the PI runtime.

If you want to remove a mock response, select corresponding structure node and choose ‘Delete Mock Response’. The corresponding response structure is marked with a  overlay.

Save the message exchange draft to reflect the changes.

Change Communication Pattern

The value of communication pattern is used at the processing step. It indicates which quality of service shall be used at the runtime (Best Effort or Exactly Once). In contrast to test case, where communication pattern is not editable and must be defined at creation time, in the test data draft you can switch communication pattern any time.

But use this operation carefully. A synchronous message exchange has not only major structure differences in comparison to an asynchronous message exchange, but it is also handled differently at runtime. Therefore, if communication pattern is switched, all messages in ‘Processed’ or ‘Failed’ state are invalidated and move to the state ‘Edited’. The processed message exchange is deleted and the message exchange draft must be processed again.

Communication pattern switch is executed directly on the server, no explicit save is required.

Create New Test Dataset

Once you are satisfied with the content of your message exchange drafts and they are in status ‘Processed’, you can create a new test data set containing the processed message exchanges. Select one or more message exchange drafts from the list and choose  ‘Create new test dataset’. In the dialog, select a name and the test case to which new test dataset shall be added.

Figure 15: Create new test dataset using ‘Processed’ message exchange drafts

Press ‘Finish’ to create a new test data set and assign it to the test case. The test dataset will contain all selected processed message exchanges and can be used in the run configuration as usually.

Figure 16: Test dataset created using test data draft workbench

Summary

Test data draft workbench helps you to compile your own test data sets in situations, where you can’t easily extract data from your system. On one side it allows you to upload and to modify your own payloads. But on the other side it makes sure that final message exchange is generated by the PI runtime and only message exchanges, which are valid in PIT sense, can be assembled into a test dataset.

Further Readings

Understanding message exchanges

Test data draft in SAP Help Portal