Skip to Content

Recently, I saw one interesting thread http://scn.sap.com/message/13372169#13372169 in forum having a requirement to add a water mark effect to the incoming payload (PDF file) during mapping. One of the quick solution, for such requirement will  be a java mapping using external API’s such as iTextPDF which can do a water mark effect on the input PDF file/stream. Well, now we have a solution but, can we verify the java mapping code without configuring an end to end scenario in SAP PI? Obviously yes, we can test the snippet of code in standalone mode outside XI/PI, using java main method wrapper and passing the input file stream to execute (or) transform methods and writing output stream to a file. However, the standalone tests do not signify exactly the same java runtime behaviors of SAP XI/PI. So, how to proceed in such cases? Do we need to configure an end to end scenario and spend lot of time on interface testing end to end by involving various parties?

In this blog, I will explain the undocumented feature of SAP PI mapping test tab export functionality. I searched SDN, if this solution is already available, but I could not find any.

Steps:-

  1. As usual, load the compiled java mapping code classes along with required external jar files into imported archive section.
  2. Create a temporary interface/operation mapping using existing source and target message/service interfaces and under mapping choose java mapping type and then choose step1 java main class program.
  3. As usual, go to test tab and click on “Load Test Instance”. It will pop-up with File Open dial box. By default, the file type will be of *.xml type. Choose “All Files”. Now, select and open the required binary file (PDF file) from your local machine.
  4. The mapping tool will pop-up dialog box with error “Unable to display tree view; Error when parsing an XML document (Content is not allowed in prolog.)”. This behavior is obvious, since the loaded data is not XML.
  5. Now execute your mapping. The output will pop-up with error pop-up similar to step 4 along with process log. Check process log for any java exceptions that might during transformation.
  6. Close the error pop-up and process log and then export the generated output AS-IS by using export push button.
  7. By default, the output will always be stored as a zip file with data file as “instance.xml” irrespective of actual output data type. Extract the zip file and then rename the .xml extension to desired extension accordingly. The file should open with it associated application. Now we can verify the output data 🙂

Advantages:-

1. Reduced testing efforts

2. No need to configure an end to end scenario or not even active version objects required

3. Quick upload of compiled java code and load test data directly from mapping test tool

InterfaceMapping.JPG

FileOpenDialogBox.JPG

ErrorDialog.JPG

TestButton.JPG

ErrorDialogOutput.JPG

SaveOutputDoc.JPG

Extract the zip file and rename instance.xml to instance.pdf and open with Acrobat Reader application.

OutputDataZip.JPG

Result: Water marked PDF

PDFOutFile_WaterMarkEffect.JPG

That’s all.

To report this post you need to login first.

8 Comments

You must be Logged on to comment or reply to a post.

  1. Iñaki Vila

    Thank very much Praveen, I didn’t know that it was possible to test the binary files directly in ESR and with this the testing effort is reduced.

    (0) 
  2. Grzegorz Glowacki

    Hi,

    I wouldn’t think of trying to save the output, once the error was raised. I thought it means no output was created at all. Nice one! 🙂

    Regards,

    Greg

    (0) 

Leave a Reply