Skip to Content
Product Information

My take on Integration Content Advisor (ICA) in the real world!

I was super excited when SAP announced the Integration Content Advisor (ICA) which will be part of the enterprise integration services of the SAP cloud platform. I thought finally there is a product which will provide some relief to the customer in implementing B2B scenario as it is challenging at times due to the involvement of multiple departments of an IT organization. There was a lot of buzz about the capability of the tool such as  automate the B2B scenario build, small development life-cycle, one pitch stop solution for B2B libraries etc.  I thought these features will have a direct positive impact on total project cost.

Like any other SAP integration architect I was super kicked when I got an opportunity to be part of product ramp-up which provided me some early insight into the product which for me looked promising. I thought this would be one of the best options if a customer has implemented solutions using SAP cloud platform or they are looking into handling the B2B scenario mappings in house. Which are generally outsourced as it would be a complex to maintain mappings in house.

I am not going into details of what is ICA and its features as there are a couple of blogs from our experts describing these topics. If you are interested, please read the links below before proceeding further.

https://blogs.sap.com/2018/01/19/announcement-new-integration-content-advisor-for-sap-cloud-platform-integration/

https://help.sap.com/viewer/368c481cd6954bdfa5d0435479fd4eaf/Cloud/en-US/6b9fe2d753534bebadcfa9080228bd94.html

In this blog, I will share my experience with ICA when tried to implement for a customer. Here is the scenario, I talked to one of our customers who are running Process Integration ( PI 7.11) dual-stack system which consist of EDI and Non- EDI scenarios. They were due for an upgrade of the existing system and they were interested in using SAP cloud platform’s integration solution and migrate the EDI scenarios and Non- EDI scenarios from on-premise to cloud. If mappings from existing scenario  can be migrated to cloud solutions then it should be straight forward with minor tweaks. There should not be a major impact to the functionality and no longer testing cycle. Our customer has a consumption model which is a newer concept of SAP licensing. Which will allow the customer to turn ON and OFF  the services when needed which will ease the procurement process. I just want to re-iterate one thing about the system of libraries which is not part of SAP Enterprise Integration Services and they need to be purchased at SAP store.

I started to work on migrating one EDI scenario which is already existing and working in PI 7.11 into enterprise cloud. I built the connection and connected the PI system to integration services to import the mapping which was the crux of the meat. When tried to reuse existing mappings it was throwing exception related to compatibility error and error saying function library is not supported so the specific mapping could not be imported. This is one of the biggest restriction of the tool as the reason being if in case a customer is planning to migrate to the cloud and move away from the on-premise system they should be at least migrate the mappings so that it would reduce a lot of tasks related to development life cycle. It does not make any sense if the customer has to re-write all the function libraries to just migrate to cloud solutions. It can be done but no customer will sign up for this option.

I worked with SAP product development team to get this question answered as there was no clear documentation mentioning about the restriction of the tool. They mentioned that their documentation is not updated and no ETA when this feature of importing mapping with function libraries will be supported. Moving on, quick education here, when a customer buys enterprise edition of integration services they will get a couple of options to implement B2B scenarios. The first , customer get additional development components in integration tenant which can be leveraged for the development of B2B scenarios. The second option is that they get the ICA as part of enterprise integration services license and can be used to build B2B scenario and then import the artifact into the integration services and deploy the solution. This creates some confusion about which option to go. In my experience, I don’t recommend using ICA as it has many restrictions which I will summarize at the end of this blog.

The second restriction is that when you try to build a new scenario you can’t use the EDI X12 format from your existing system as it would generate many errors during testing so need to use a system of libraries which is part of ICA but purchased separately. I have discussed this issue with many colleagues, and they have agreed to my point. In theory, ICA is an awesome tool but when you implement the solution it is not at all straight forward.

The third restriction is when trying to use X12 from system library in ICA you need to manually select all the respective X12 or Idoc segments and its field that need to be used in your mapping. You can’t perform SELECT ALL. This puts additional risk on the business team, and we all are aware that any development will have multiple iterations, and nothing will be on dot in the first run. There is a bigger risk with this limitation. When an enhancement needs to be performed on existing mapping it would impact the existing mapping and introduces a longer regression test cycle which no customer will entertain.

Last but not the least, when you try to develop the mapping in ICA only XSLT mapping is supported and no scope for any graphical which is like chopping off the legs and trying to run a marathon. Painful!

Finally, my experience with ICA was not that exciting and to sum up all the issues ICA is not a straight forward tool. It needs development iterations to mature and become a robust B2B implementation tool. I am sure it will get there but not for now.

Summarizing ICA tool limitations

  1. No graphical mapping only XSLT in ICA
  2. Existing mapping poses compatibility issues if the function library exists
  3. Function library is not supported if it is part of mapping
  4. Reuse of X12 is not compatible and poses lots of challenges during testing (the only X12 from the library of system needs to be used)
  5. ICA can only be used for standard mapping with no Z Idoc fields
  6. Manually need to select segment and fields in the library for  X12 or Idoc type

Like I mentioned earlier this is my take and not a general perspective about the tool. If you have good results using ICA please share your business scenarios as it may be helpful to the community.

Hope this helps!

See you in my next blog!

7 Comments
You must be Logged on to comment or reply to a post.
  • Nice blog Hari Sonnenahalli and really valuable to provide your experiences to the wider SAP Community – well done! From what I have seen the idea of the ICA is seriously sound and while it may not handle all integration scenarios I was hoping it would cover the 85% of scenarios. If not now, then in the future. Hearing real world experiences usually make products like this one so much better and as it is a relatively new addition I would say it can only get better.

    Thanks for sharing your valuable experiences.

    cheers

    Phil

    • It is cool concept product. If it gets matured it would be one of the best options for B2B. I think as of now it needs enhancement of features to have an easy B2B scenario development.

      As long as it helps community.

       

      Regards

       

      HS

  • Dear Hari,

    many thanks for your honest feedback and sharing the experiences with us. The Integration Content Advisor is a completely new built product covering a completely new paradigm and like you said, it gets matured. This is what we’re doing with high pressure. We know about all the mentioned limitations and issues. You’ll find the relevant enhancements in our roadmap: https://www.sap.com/documents/2017/06/88bff829-c37c-0010-82c7-eda71af511fa.gate.html

    But let me explain the intentions and enhancements in more detail with your summary list of limitations:

    1. No graphical mapping only XSLT in ICA – The MAG editor is from our point of view the graphical mapping tool. It currently generates XSLT. A generation of mmap files is on the roadmap. Furthermore, we decided not to implement a graphical tool for the mapping functions. Because we recognized this functions tool box does not increase the efficiency. Especially, if you want to create very complex functions. It is much more efficient to write functions by using a script language. In order to not to define our script language, which just took over the XSLT / XPath functions. These will be directly inserted without any further transformation. In one of the next releases, you’ll find a function tool box in where you can globally store your reusable functions. Regarding functions, our goal is the following:
      • Reduce the number of functions as much as possible. We already consider some concepts like the qualifiers and the mapping semantics by consideration of the source/target property. We also have a number of further concepts in our pipeline for further reduction of functions such as complex patterns and intelligent sorting.
      • Proposal of functions – The knowledge graph of the Integration Content Advisor is at the starting point. But our is intention is that you will get best fit proposals to the mapping elements. For this reason we already started to train the graph and especially extended the algorithms this will work sufficiently.
      • Better descriptions of functions – We know, first two points will not fulfill all the requirements. You can still define your own functions. But in order to understand and find these functions much better, we will provide a number of fields in where you can describe the behaviour and the intention of the functions in detail.
    2. Existing mapping poses compatibility issues if the function library exists
      • I’m not pretty sure, if I understand this limitation correctly. You want to reuse your existing functions in a mapping generated by ICA. This was not tested and in our scope yet. But we would like to invite you to talk about this limitation in more detail.
    3. Function library is not supported if it is part of mapping
      • We don’t support the PI/PO functions and especially the UDFs yet. This has two reasons:
        • ICA is focused on XSLT/XPath expression
        • ICA covers a complete new paradigm with the aim to reduce the number of functions.
      • But anyway, we would like to discuss with you which kind of functions and how they should supported.
    4. Reuse of X12 is not compatible and poses lots of challenges during testing (the only X12 from the library of system needs to be used)
      • I’m not sure what do you mean with compatible.
      • But regarding your statements in “The third restriction ….”. This approach is intentional. Some of the X12 interfaces allow several billion possibilities on semantic level. For example, with the 850 purchase order, you can express more than three billion different business meanings by using the different qualifications. It is very hard to find the appropriate ones. Therefore, the idea is that you customize this 850 by just selecting the necessary ones and define the very specific qualifier variances for groups such as N1 (Address), CUR (Currency) or DTM (Date/Time Reference), etc. This qualifier variances has two advantages:
        • It increases the readability of your interface specifications
        • It reduces the number of mapping functions (see point one). We calculated, that you can save up to 60% of your functions in a X12 to IDoc mapping by exhaustively using the qualifier variances.
      • It is furthermore on our roadmap that you can do an editing of the source and target interface structure in the MAG editor.
    5. ICA can only be used for standard mapping with no Z Idoc fields
      • This feature is on our roadmap. It should be available by Q3.
    6. Manually need to select segment and fields in the library for  X12 or Idoc type
      • As I said, this is intentional (see unter point 4). As I also said, Integration Content Advisor is a paradigm shift and not just another mapping tool. You have to especially define all the requirements, properties, limitations and boundary conditions in the MIGs (Message Implementation Guidelines) like required cardinalities, length, used elements, supported code values, qualifier variations etc. As more as these aspects are defined in the Message Implementation Guidelines, as simpler will be the mapping in the Mapping Guideline.
      • For further improvement and acceleration of these Message Implementation Guidelines, we have three further features on our roadmap:
        • Payload uploader, which generates the customized interfaces (MIGs) by uploading payload/instances
        • mmap uploader, which generates a sceletion of a MAG (Mapping Guideline) and corresponding MIGs according the rules and definitions in the mmap file. Disclaimer: The first release will have limitations such as no support of functions.

    I hope my comment clarifies your points and concerns a little bit more. I appreciate it very much, if we can set up a meeting in very we can go through your points in detail and in where we can discuss about you, how this can be solved by the Integration Content Advisor.

    Like you said, the Integration Content Advisor is a cool concept. But it is new and we need also your support for getting it mature in the right direction.

    Many thanks in advance.

    Kind regards,

    Gunther Stuhec

    1.  
    • Gunther-

       

      I really appreciate you taking time and explaining the roadmap and product scope. I have questions regarding the tool. If these questions are addressed will help us set correct expectations with client. Please let me know if you prefer to discuss or schedule a meeting.

       

      Regards

       

      HS