Skip to Content

As a quick introduction to SAP conversion agent by Informatica, a very well-known and widely used parser/ serialize is will no longer be sold by EHP 1 for SAP NetWeaver 7.3. This puts any upgrade projects heavily dependent on conversion agent in a state of limbo. This article deals with the shortcomings of PI’s out of the box concepts vis-à-vis conversion agent and looks at possible alternative approaches. The scope of this document is limited to dealing with data streams/ flat files (fixed length or CSV). It can be extrapolated to PDF or Excel sheets, but not all arguments are valid in those cases.

Conversion Agent is a data conversion system that enables you to create interfaces between any data formats and XML-based systems. The Conversion Agent can convert unstructured, semi-structured, and structured formats to XML, and the other way around. Prior to SAP NetWeaver 7.3 EHP1, Conversion engine module could be used on any of PI’s Java based Adapter’s.

However with SAP not supporting conversion agent anymore it’s imperative to find an alternate solution to Conversion Agent. In a way the projects that never used conversion agent find themselves in a safe zone. At times it’s easier for a PI architect to put forth a limitation and have connected systems deal with it. However in many instances where conversion agent has been implemented and one needs to migrate them to the newer platforms PI 7.3 EHP1 onwards.

Following are easy to understand decision tree:

DecisionTree.png

Some of consideration that goes above is as follows:

1.0: Cost

Lot of costs already factors it in a SAP PI upgrade project. Some of these costs  are not only limited to PI development/ support team alone, but are also applicable for PMO, process teams, infrastructure teams, connected systems, test teams and business representatives. If any of the interfaces marked for upgrade use CA, the decision on how much would it cost for these systems to change the format to match up PI’s expected format vs. having PI to do look for alternate approaches is a vital one.

2.0: Is the upgrade imperative?

Evaluate if your organization really needs to upgrade. Per the Project Evaluation Matrix, for NetWeaver PI 7.1 or NetWeaver PI 7.4 end of mainstream maintenance is up until 12/31/2020. Is it just the development team fancies an upgrade? Has anyone prototyped using the new PI server and it does what you expect it to do? If it does, would you spend the amount you are for those features? Do you have a migration and support strategy in place for the new PI environment? Do you see any other roadblocks? It’s important to look at upgrade holistically. If you are missing any of this information, it’s time to go back to the table and weigh them in before making your decision.

3.1: Are there alternate tools/ modules that can replace CA?

Check if there are any alternate tools that can give similar results like conversion agent. The risk of doing this is that you may quickly get dependent on that too and just like conversion agent you may want to define a replacement strategy for that in the future. Using this approach we would merely procrastinate the decision of living with an external conversion tool and also pay for the additional licensing cost of the new tool.

3.2 Dual PI environment

One easy way of achieving an upgrade is to keep the conversion engine based communication channels on a decentralized PI 7.1 adapter engine and upgrade everything else. By that way your conversion agent based communication channels still continue to work as they are supposed to. They decentralized adapter engine keeps exchanging information with the integration engine seamlessly. The flip side to this approach is that you will need to keep maintaining a decentralized adapter engine, which is actually not much.

3.3 In house replacement for Conversation Engine

This is the most recommended of all the approaches. However one needs to know how to replace the conversion agent. For once I wanted to understand what the conversion agent (CA here on) provides in flat file based scenarios that the normal built-in messageTransformationBean  (MTB here on) does not:

Here is a list

01. CA could handle files a single line file with header and items graciously. However for MTB, the segment should start with key field.

The following cannot parse correctly on MTB

HDR,HDRFLD1,HDRFLD2,ITM,ITMFLD1,ITMFLD2,ITMFLD3,ITM,ITMFLD1,ITMFLD2,ITMFLD3


02. CA also handles fields that don’t start with a Key whereas MTB does not.

HDR,HDRFLD1,HDRFLD2,ITMFLD1,ITMFLD2,ITMFLD3,ITMFLD1,ITMFLD2,ITMFLD3

In this case since ITM is not a key that you see in the data, MTB does not recognize item node. However CA has a way of understanding that if a key field is not present, then it can insert a key field (conditions applied).

03. CA understands keys that have spaces under towards the end whereas MTB does not.

                    HDR  HDRFLD1HDRFLD2

                    HDRCRHDRFLD3HDRFLD4


TS recognizes both the above lines as HDR. Where as CA is able to identify HDR from HDRCR. Even if spaces are configured in the MTB, they get truncated when read by the actual module.


04. CA supports calling of other CAs. MTB does not. Just assume the case of a data coming in as a flat file with characters 3-5 determining the segments/ fields that follow afterwards.


05. Nesting of depth greater than 3 is not supported in the MTB, but is every well supported in CA.

A good solution would be to implement custom modules that you can control rather than depending on 3rd party applications. Not a difficult thing to do. The main effort is expended towards development and support of the custom modules. Most of the modules developed on these lines are at the least supported on version 7.1, 7.1 EhP1, 7.3 and 7.4 and will be supported going forward unless SAP changes it architecture drastically.

To report this post you need to login first.

5 Comments

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

  1. Dimitri Sannen

    Hi,

    Thank you for sharing…

    Just to add up to your comments: we used the Conversion Agent within the IAH adapter (formerly known as HL7 adapter). Now, we still use the IAH adapter, but it produces HL7 XML and no more a flat structure using Conversion Agent.

    Perhaps you want to avoid custom adapter modules and try it using standard SAP PI or PO features.

    Kind regards,

    Dimitri

    (0) 
    1. Keerti Nayak Post author

      Hi Dimitri,

      Agreed – As you mentioned, I too believe the right way to go about it is to use the standard and depend on the tooling features. If the standard does not serve the purpose, it would make sense analyzing the gap before jumping on to a 3rd party application assuming that me may use features we not really need. Many implementations are spending tons of money recovering from such bad decisions. 

      Regards,

      Keerti

      (0) 
  2. Anil Kumar Vaitla

    Good Post Keerti. Totally understand your frustration. We always have these risks when using Third Party components. In our current project we have a similar situation with a tool called credibleXML (to convert EDI to XML).

    (0) 

Leave a Reply