Skip to Content
When I was thinking about the evolution of SAP PI and the new version that will be soon released, I did the following questions to myself: Why exist two independent development tools for SAP PI?

It’s an old question that all students in SAP Training courses have made me and I  have never been able to answer them with enough conviction because I think the same.

I think some of the improvements that SAP should implement in the next versions should be:

  • Only one development tool. At this moment, I don’t know why SAP doesn’t integrate both development tools in a single one. 
  • SAP Netweaver Developer Studio. As SAP has adopted Eclipse for the Java development enviroment, why don’t they use eclipse for the PI development? It’s a good tool for developping Java programs, XSD, XML, etc
  • Java Module plugin. It would be necessary to have a plugin to develop our own module adapter and be able to enhance the features of the standard adapters.
  • Adapter Plugin. It’s a good point to have an Adapter module plugin for SAP PI as well. It would be good to create adapters from scratch.
  • Change BPEL to BPMN notation and integrate Galaxy as SAP PI BPM tool.

In the beginng these are some of the proposals that come to my mind.

Summarizing, I think that SAP should adopt Eclipse as base platform for development, both Java development and PI developement. 

Don’t you think?

On the other hand I have severals findings about some features that SAP should improve:

  • The import IDOC/RFCs methods. When we search for a particular IDOC or RFC all information of IDOC/RFC in SAP System is downloaded. This is a very heavy task for the virtual machine memory, why don’t download only the information or data required ?
  • The memory management. Now the memory management isn’t optimized, I think SAP should work harder to fix this issue.

 

What are the things that SAP has made better?

  • The use of the CTS+ as method of transport of PI objects .It was a good choice.
  • The use of individual repository for SAP PI Objects, it was good that SAP had not integrated the repository object into NWDI.
  • The monitorig enviroment. I have always found all the error messages I was looking for in a short time.

What do you think about the improvements that SAP should apply in the next SAP PI versions?

To report this post you need to login first.

10 Comments

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

  1. Christian Sy
    Yes, merging the configuration and design objects into one tool would be a great help. I also never understood why that was separated, we always have to switch. And even better, the tool should be able to login to several systems at once, so that we need only one main window. Currently, when we are transporting objects, we usually need 4 separate processes (Design Dev, Design Prod, Config Dev, Config Prod). Considered that the XI/PI IR/ID Java applications are not caring very much about memory management, that is no good idea.

    Many more functional wishes can be found here:

    http://wiki.sdn.sap.com/wiki/display/bpxproj/Effective+PI

    (that was from 2008. Some of them have been included or improved in the meantime for the newer PI versions).

    CSY

    (0) 
  2. Vijayashankar Konam
    I think SAP purposefully bifurcated the design and configuration environment and I would support that. If you look from SAP perspective, SAP would never supply any configuration elements from SAP standard PI content. This is because, every client might use them in a different way. The only thing that is constant everywhere (in PI landscape) is the the Development Objects. You can authorize based on the roles whether one can change the design/configuration objects.

    I know all this can be possible in  single tool as well. But having them separated would eliminate lot of things going wrong in the first place..!!

    VJ

    (0) 
    1. Christian Sy
      I do not get your argument. I agree that access can be easily handled by the roles. So what could go more wrong compared to 1 window instead of 2?

      CSY

      (0) 
  3. Paul Hardy
    When you first start learning about XI/PI it seems crazy. You log into the ABAP system, and then you have to log onto three different systems – SLD, integration design and integration configuration – putting your password in again each time.
    We have always been told the whole point of SAP was that it was an integrated solution, so you could do all your work in one place without having to constantly log into and out of disparate systems. XI/PI seems to be the reverse of that.
    Many commentators have said that if XI was all in one language – all ABAP or all Java – then you wouldn’t have the overhead of data moving between the different stacks and there would be less diffreent systems to log onto. In my XI training course the whole training class come to a gridning halt when the two stacks stopped communicating with each other, which was really embarassing for the trainer. (This was at SAP Melbourne, by the way).
    If you want to isolate the two halves into different applications, then great, but to me the ABAP data dictionary and program writer are linked but different transactions, and I can use them both all in the one system.

    Cheersy Cheers

    Paul

    (0) 
  4. Dimitar Margaritov
    Hello,
    what is wrong from your prospective with memory management in PI (I assume you are talking about the java part)? What effects have you observed? How do you think they should be fixed?

    Thanks,
    Dimitar

    (0) 
    1. Carlos Ivan Prieto Rubio Post author
      Hi Dimitar,

        Firstly, the IDOC import options doesn’t work if it’s download from a system with many RFC/IDOCs. We have opened a SAP Note with this issue because in one of the systems that we are working the ESR doesn’t work.

        On the other hand, when I’m working with Integration Repository there are times where the tools is too slow. In Microsoft Window’s task manager we can see that the memory assigned to this process is about 500 – 600 MB. I think that it’s not normal. Don’t you think?

        For fixed this problems I think that it would be good change the ESR application to Eclipse. I think that memory management of eclipse works better than ESR. For the IDOC import issue the way for fix it would be to make the find/search by means RFC in ERP system directly and not download all IDOC/RFC metainformation to ESR.

      Regards and thank you for you response.
      Iván

      (0) 
    2. Christian Sy
      Hello,

      try to load grpahical mappings which map between an Idoc and a Seeburger Edifact structure (e.g. invoic02 to invoicD96a). You will notice that every mapping object consumes between 50 and 100 MB, regardless what the mapping logic is (without test-instances !), and without even going in test mode and execute it. That is quite annoying, because then we can load only about 5 mapping objects, then memory is full.

      Obviously the XSD structures (or other mapping structures) are not cached, and use a very high amount of RAM (not only for Seeburger, also with other XSD’s). That is bad for performance. It should be improved. Although the Idoc and edifact XSD’s are not simple, there is no reaon why a mapping object should consume 50 MB+ memory when it is properly programmed.

      Especially the Integration Builder has these memory problems. Integration Directory is acceptable, because the amount remains quite stable, although also quite high.

      Hope this helps a bit.

      CSY

      (0) 
      1. Christian Sy
        Follow-up to last reply, this behaviour is since at least XI 3.0 SP 21 and continues in PI 7.1 EHP1. On the server side, there have been noticable improvements about memory management: while in XI 3.0 it was common that the Java Stack rebooted sometimes because of OutOfMem every few days, PI 7.1 does not seem to have that problem anymore, it runs more stable.

        But the client side memory management has not improved, at least we could not notice it.

        CSY

        (0) 
  5. S. Gokhan Topcu
    I think most of these points are already caught by SAP already. Roadmaps & presentations already indicate that:

    1. PI is moving to be a Java-only tool
    2. Unification of BPM modeling – an overall SAP effort in all areas already, I’m sure PI will get its share
    3. Eclipse design & configuration – declared too, will be there probably in the next version.

    Regards,
    Gokhan

    (0) 

Leave a Reply