Skip to Content

Recently I’ve seen the question about the ability to change messge data (or even message structure) in file pass-through scenario.

As we speak about “pass-through” it means that we didn’t do any ESR development, thus we have no existing mapping objects in hands.

Ok, let’s take that question as basis for our test scenario.

We have a source message containing some employees info in the form of .csv flat file:

ID0001,John Smith,20011001,Male

ID0002,Mary Ann Key,20000321,Female

And we want to send this message to receiver system in XML format:

       <ns:MT_Employees_List xmlns:ns=”urn://ns_train>

        <Employees>

          <Employee>

           <EmployeeID>ID0001</EmployeeID>
           <Name>John Smith</Name>
           <DateOfBirth>20011001</DateOfBirth>
           <Gender>Male</Gender>

          </Employee>

          <Employee>

           <EmployeeID>ID0002</EmployeeID>
           <Name>Mary Ann Key</Name>
           <DateOfBirth>20000321</DateOfBirth>
           <Gender>Female</Gender>

           </Employee>

        </Employees>

   </ns:MT_Employees_List>


This pass-through scenario can be easily done by setting up File Content Conversion in our sender File channel and creating ICO object with dummy interfaces/namespaces in Integration Directory.

Now let’s slightly change our requirements and say that we want to have emplyee’s birth date in “dd/mm/YYYY” format in our target message (as per requirement in question mentioned above). As I’m lazy enough to start with ESR development or custom adapter module implementation in this case I’d prefer to unleash the power of XSL transformation and let the MessageTransformBean do the most of work instead of me 😉 .

XSL transformation for data format change:

<?xml version=’1.0′?>

<xsl:stylesheet version=”1.0″ xmlns:xsl=”http://www.w3.org/1999/XSL/Transform“>

<xsl:template match=”@*|node()”>

  <xsl:copy>

    <xsl:apply-templates select=”@*|node()”/>

    </xsl:copy>

</xsl:template>

<xsl:template match=”DateOfBirth”>

  <DateOfBirth>

  <xsl:value-of select=”concat(substring(., 7, 2), ‘/’, substring(., 5, 2), ‘/’, substring(., 1, 4))”/>

  </DateOfBirth>

</xsl:template>

</xsl:stylesheet>

We put this transformation to our PI server file system and just add the MesasgeTransformBean in our receiver File communication channel with parameters:

Transform.Class = com.sap.aii.af.sdk.xi.adapter.XSLTConversion

XSLTConversion.XSLTFileName = /usr/sap/PID/SYS/global/NOVATOUR/Inbound/XSLT/BC_Train_Test.xsl

As the result we can see desired changes in message data:

<ns:MT_Employees_List xmlns:ns=”urn://ns_train>

<Employees>

<Employee>

<EmployeeID>ID0001</EmployeeID>
<Name>John Smith</Name>
<DateOfBirth>01/10/2001</DateOfBirth>
<Gender>Male</Gender>

</Employee>

<Employee>

<EmployeeID>ID0002</EmployeeID>
<Name>Mary Ann Key</Name>
<DateOfBirth>21/03/2000</DateOfBirth>
<Gender>Female</Gender>

</Employee>

</Employees>

</ns:MT_Employees_List>

Regards, Evgeniy.

To report this post you need to login first.

3 Comments

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

  1. Eng Swee Yeoh

    Hi Evgeniy

    Thank you for sharing this.

    Whilst this approach is entirely possible technically, IMHO such an approach needs to be weighed against a holistic development approach that takes into consideration the lifecycle of the development/interface.

    An example of things to consider are:-

    – version management – how to maintain changes to the XSL file that is stored in the PI file system

    – testing – what tool to use for testing the XSL prior to deploying it to the file system

    If we use ESR for the development, both of the above are covered natively.

    Whenever changes/transformation is needed for a so-called passthrough interface, IMHO it is important to reconsider if it is more beneficial to use ESR than to “force” the interface to remain using a passthrough ESR-less approach.

    Regards

    Eng Swee

    (0) 
    1. Evgeniy Kolmakov Post author

      Hi Swee Yeoh!

      Thanks for your reply.

      You’re absolutely right. In most cases we should go for ESR development.

      And approach described above just gives a solution for cases when ESR development or adapter module development are inapplicable for any reasons.

      Regards, Evgeniy.

      (0) 

Leave a Reply