Process Integration (PI) & SOA Middleware: We don't want Java on SAP PI

Posted by Daniel Graversen Oct 7, 2013 I was working with a client doing Bank (BCM) integration on the SAP PI platform. Everything was going well. Then I got into a talk around if we could get rid of this Java thing. Then I had a small issue Since my focus was to make everything in the integration layer as simple as possible and be able to upgrade it. So it would be possible to go to the single stack. The claim was fair enough that the bank department did not have enough skills on the Java to support a lot of java code. There was enough ABAP developers around, because they had worked with ABAP for 5+ years. They had the skills for coding and supporting ABAP, in that perspective it was much easier for him and the team to support it. The same does I see when I do consulting with smaller clients, where they only have a basis or an ABAP developer to handle the PI as a side project. How many things can you handle and support before it is too much. They seem to have gotten the idea that SAP was moving away form Java. So all business logic from SAP will be in ABAP. They thougt of this because of the Oracle acquisition of Sun. My comments was that in my view SAP was still investing heavily in Java both for the PI/PO and for the cloud applications. I recorded this video around the issue. I think we got to an agreement on what should be different. The big issue was about maintain lookup values for the business. Most of the values should be maintain on the ERP system, which is not a complete goodbye to the Java stack. And ABAP mappings was never in the scope. I still think it is a valid point, what are you required to now inhouse before you can maintain a SAP PI system. Do you need to be PI certificed or can you just have some skills in debugging and monitor the PI system? 1528 Views Tags: java, sapmentor, sap_netweaver_process_orchestration, process_integration, abap, video, architecture, pi_731, po, pi_7.31

Eduardo Chiocconi Nov 5, 2013 11:20 PM Hi Daniel, Thanks for posting this message and more importantly bringing this discussion front and center. I wanted to share my impressions and observations as to why it does make sense to move into a single Java Stack.

Generated by Jive on 2013-12-12+01:00 1

Process Integration (PI) & SOA Middleware: We don't want Java on SAP PI

1. For the record, NW PI will continue to be supported on a dual stack deployment, but the new innovation will happen mostly on the Single Java Stack. So for those that prefer to do coding in ABAP this will be supported. In the same spirit, if there are developers with Java background they can also take advantage of the Java deployment. But I think it should be clear by now that NW Process Orchestration has definitively gone a trajectory of moving to a model driven approach there you can do a lot with drag and drop and mapping components to avoid the need to go into code. For those occassions where coding is needed, there is the option of both Java and ABAP if this is a heavy enough requirement to dictate which deployment option to choose. In my experience, this should not be the case. 2. NW Process Orchestration is not just NW PI. It is the aggregation of multiple services (A2A, BPM, BRM, B2B). The common middle ground to support them all together has been on the Java Platform. This is a front and center decision as we are looking for a full middleware suite including use cases covering A2A (stateless integration scenarios), BPM (stateful integration scenarios) and B2B. This is where SAP customers start getting more value for their investments. This has also placed SAP's offering closer to the other players in the space. 3. NW Process Orchestration is not to integrate SAP to SAP, but to address the HETEROGENEOUS landscape in a company. This is why we try to embrace different standards and play a more open integration path. Implementing NW Process Orchestration on Java also allows embracing the open standard community better. Although for ABAP developers SAP may be in the center of the universe, the integration strategy should be more open. The more Process Orchestration continues to support more model driven improvements, the less we will need to do programming in a specific language and the easier these solutions will be able to get modified over time minimizing the end tail of cost. I have spent quite some time talking to existing customers and more importantly new SAP customers investing on middleware strategies. Architects tends to appreciate the openness of the platform and how the previously mentioned services are coming together. They see this as a clear good vision that also matches the market trends too. As always we bring a specific special twist to the stack to make it the best around SAP (like close integration with Solution Manager, etc), but in order to be a first class citizen on the integration space, supporting open standards is the way to go. Look forward to your comments. Eduardo. Nabendu Sen in response to Anupam Ghosh on page 4 Nov 5, 2013 1:59 AM Hi Anupam,

I am really happy that we both share same kind of reason to get into PI. Thanks for the reply. Regards, Nabendu. Daniel Graversen in response to Suseelan Hari on page 4 Nov 3, 2013 5:41 AM

Generated by Jive on 2013-12-12+01:00 2

Process Integration (PI) & SOA Middleware: We don't want Java on SAP PI

Yes it is amazin how many like the topic and want to share their comments.. Daniel Graversen in response to PEDRO DOMINGUES PEREIRA on page 4 Nov 3, 2013 5:40 AM Hi Pedro Thanks. Yes it seems to spark a fire. Yes it is two different paradigms around what kind of topic we are dealing with. Coding ERP and coding interfaces. Some part of the syntax and the coding is the same no matter if it is interface or erp coding in abap. For PI for me it makes sense to get rid of the ABAP stack. Daniel Graversen in response to Carlos Ivan Prieto Rubio on page 3 Nov 3, 2013 5:36 AM Hi Carlos You are right. We all have to evolve our skills to support the technology that is changing. If you are forced to learn it you can. Carlos Ivan Prieto Rubio Nov 2, 2013 5:52 PM Hi Daniel,

Java Stack is relatively new in SAP world. I remember that XI30 was a poor enviroment in all senses, about performance and stability.

Now I think Java Stack is more stable than eight years ago, better perfomance, funcionality and stability. As you know the 95% of integration platforms are based in Java Technology (Webmethods, WSO2, Tibco, etc ... not Biztalk I know) and SAP must to go in this way. ABAP Stack had to take many years until get a good stability.

Now there are many Java EE Architects with good knowledge and skills that can join to SAP PI developer teams to improve all around the projects.

For those small clients with only ABAP developers skills: why don't they learn about Java technology? I started my career developing Java EE projects, then I moved to integration projects, then I had to learn about SAP Basis knowledge and ABAP programing, ALE Technology etc etc. Now I'm learning about SAP MDG .... We are in technology world !!!

Generated by Jive on 2013-12-12+01:00 3

Process Integration (PI) & SOA Middleware: We don't want Java on SAP PI

Regards Ivn PEDRO DOMINGUES PEREIRA Oct 31, 2013 1:39 PM Hi Daniel, Nice topic to set things on fire... Let's get rid of ABAP STACK instead... SAP have a very good product here, as it is and not as you want it to be! Designing, programming and usage of middleware SAP PI is a different thinking paradigm that most ABAP coders (not all), that i know, tend to elevate to a complex monstrosity , as it is an unkown realm... (maybe the task of documentation reading is a complex issue)

Best Regards, Pedro Pereira Anupam Ghosh in response to Nabendu Sen on page 4 Oct 30, 2013 5:00 AM Hi Nabendu, Its because of java I got into PI and not that I was into PI and then got in java. Thus the day java moves out of PI, I guess will be my time to retire too. I fully support SAP moving towards java this somehow paves way to high quality custom development and use of PI in non-SAP landscape. Regards Anupam Suseelan Hari Oct 30, 2013 4:17 AM Hi Daniel, Good Day! It is quite interesting topic. Nice to read and liked the way you have presented. Also I liked all the ppl discussion in this blog. Regards, Hari Suseelan Nabendu Sen Oct 30, 2013 1:07 AM

Generated by Jive on 2013-12-12+01:00 4

Process Integration (PI) & SOA Middleware: We don't want Java on SAP PI

Hi Daniel, I totally agree with Anupam and James. I still think SAP took long time to take this right decision about the concept of Java based Middleware, where other competitors are already ahead. First of all, it should be obvious to a middleware consultant / developer that for any custom requirement 100% avoidance of code would not be possible. Java is no doubt a better option with respect to integration platform and SAP PO still needs a lot of features / flexibility to be added to give a good fight with others market leaders. We should not get confused with other mainly ABAP stack SAP applications like ECC/CRM/BW/SRM with PI, it demands different expertise. If we again try to see the future of PI through ABAP, it would create limitations to emerge PI as a convincing "Middleware" where Sender / Receiver is not a SAP product. Rather it would again create an idea of a product just to integrate different SAP systems and believe me still lot of clients have this. Still today it is hard to find projects where PI is used as a middleware without the existence of other SAP products in the system landscape. So, PI really demands a lot positive moves, investments from SAP side and we are eagerly waiting.

May be I am little bit partial about Java, but all from my own experiences. Regards, Nabendu. James Wood in response to Anupam Ghosh on page 5 Oct 18, 2013 2:14 AM ABAP can definitely do it, but Java is much better at bit-twiddling, XML parsing, and so forth. To me, it's not so much a language issue as a data issue. Java's a fantastic language, but with all the data over on the ABAP stack, it's hard to achieve full blown process orchestration with PI/PO. It's not that the Java-based implementation is bad, it's just too isolated in my opinion. Anupam Ghosh in response to Daniel Graversen on page 6 Oct 18, 2013 1:41 AM I remember one scenario where I had to print each bit of data as it is and even had to rotate and manipulate the bits. Please have a look into this thread. I am not sure if ABAP can handle this case, specially when you also have IEEE32 bit floating point format. Anyways I feel java/ABAP programming gives us necessary food for thought. ABAP is after all a programming language , thus any one who writes ABAP code must be having sense of logic. It should not take much time for him / her to pick up java as well. Specially when editors are available in local system. For ABAP we need the SAP login and developer key to start coding which is not essential in case of java. When I try thinking of life without coding , then SAP becomes a place of procedures. Don't you feel creativity takes a back seat when we have only procedures and no place to show independent thinking? To remove java completely means SAP has to have functions , adapters equipped with more functionality , so that we don't have to code. This is not possible since business is changing rapidly. The way

Generated by Jive on 2013-12-12+01:00 5

Process Integration (PI) & SOA Middleware: We don't want Java on SAP PI

any organization operates is much different than the way it used to operate say 5 years ago. The complications are increasing everyday thus to reduce complexity SAP has to leave space for coding. Secondly processing speed depends on hardware. I understand processor speed has increased in leaps and bounds.But bus speed is much lesser than processing speed. What I mean to say is that it takes more time for processor to fetch the data from hard disk than processing it after fetching. If SAP say manages to in build, all the functions and features removing the need for java coding (if necessary) then this will affect system performance. Both required and not required functions will get loaded once user logs in. Maybe I am used to coding, hence supporting it but all this is my personal opinion and respect yours too. Daniel Graversen in response to Anupam Ghosh on page 6 Oct 17, 2013 8:35 PM I believe that ABAP is capable of dealing with binary files. Otherwice it would not be possible to use ZIP http://wiki.scn.sap.com/wiki/display/ABAP/Zip+any+file+via+ABAP+using+CL_ABAP_ZIP Anupam Ghosh Oct 17, 2013 3:20 PM Hi Daniel, Does ABAP has capability to reach each bit of a byte of data? In very simple terms can ABAP manipulate/rotate/interpret each bit of data? If answers to these question is "no" then, I feel, SAP is doing right thing to shift towards java. There are certain scenarios for example reading binary files where we have no option but to use java. At the same time , I feel, we should avoid writing codes as far as possible be it ABAP or java. Regards Anupam James Wood in response to Daniel Graversen on page 6 Oct 11, 2013 2:02 PM No, I think that ship has sailed. I think its future is, for better or worse, tied to the Java stack. My point was more around whether or not this was a good approach. In my estimation, it's hard to build an effective Process Orchestration hub without convenient access to the business data/rules needed for it to do its job. Since PO currently sits out on a Java island of sorts, I think the development costs are prohibitive for many customers to use it as much more than a replacement for the BPE in PI. Indeed, even the simplest of processes probably require at least 2-3 service calls (e.g. to ECC) to do something productive. Daniel Graversen in response to James Wood on page 7 Oct 11, 2013 12:24 PM Hi James, Do you expect the PO to be moved to Abap only in some form, which contradict their lates move. I know that in the begning it alternated between java and abap only solutions. But we have a much different level of manturity on the product now. Daniel Graversen in response to Stefan Hilpp on page 7 Oct 11, 2013 12:21 PM

Generated by Jive on 2013-12-12+01:00 6

Process Integration (PI) & SOA Middleware: We don't want Java on SAP PI

Hi stefan I know that the seeburger package consists of a lot of good modules for B2B, which makes things lot easier. Sometime a small java module can save lots of complexity in later mappings or extra flows. I admit that I have created a lot of java mappings to handle different business logic like updating status in different areas. It is not something that I recommed but it was somehtign the business asked for. So they got it. And the more requirement they are bringing there more complexity is build in to the mappings. James Wood in response to Stefan Hilpp on page 7 Oct 10, 2013 5:28 PM This mindset is very interesting to me, and I think it's a mindset that's widespread throughout the PI community. Coming from a Java background and having worked with a lot of non-SAP EAI tools, this seems very foreign to me. For developers working with the competing tools, Java, XML/XSLT, and SOAP/WSDL are core skill sets, not optional ones. I think this is where things come to a head when you start talking about a Java-centric single stack architecture. The danger from an SAP perspective is that a Java-centric solution lumps them in with a lot of competitors who have Java-based solutions that are more mature and robust. As PI/PO and EP are about the only Java players left in the landscape, it makes you wonder if/when SAP will decide that the Java investment is still worthwhile... Stefan Hilpp Oct 10, 2013 12:15 PM Personally, as a Consultant (mainly in the B2B area), I try to avoid any own Java-Coding whenever possible, also based on the fact, that I am not a Java-Developer but a PI Consultant. Furtunately, by using the Seeburger EDI-Adapters in my projects (and I think that same should be true for the other B2B-tools available on PI) , there was no need to use any special Java-Coding in the Channels, as a lot of modules are existing for all EDI-retaled tasks that need to happen in the channels. Also by using the graphical mapping, I could also avoid to use Java to a very big extend in the Integration Repository. This also allows for good troubleshooting and debugging by using the available functionality. And it gives every other PI-Consultant the possibitily to easily see directly in the Mapping-Tool what has been mapped. (However I very much like the UDF-possibility, as it is usually limited to one target filed and you can reuse this code also on other mappings). I have seen customers that had very customized scenarios with Java-Mappings and own Java-Modules executed in the channels...and the problem always is, that only the developer that has implemented this, really knows whats going on and can provide quick help in case of errors. By using available modules (as part of some adapter-packages) any PI-Consultant has a decent chance to debug and understand whats going on in the channels. Anyway...just my personal experience ... (and maybe it would be different if my java-knowledge would be better ;-) )

Generated by Jive on 2013-12-12+01:00 7

Process Integration (PI) & SOA Middleware: We don't want Java on SAP PI

barry neaves Oct 9, 2013 2:37 PM i am torn about Java in PI. personally i don't like Java in my mapping if i can help it. i do not like any/many rules at all. a conversion here or there is one thing, but i feel the business systems should take care of any complex business rules. it should not be held in the integration area. i like PI single stack though. i feel it is much more lightweight, less points of failure and even though it is relatively new, it seems really stable..

besides if you want to have ABAP in your single stack, that's what SolMan is for! anyway, my 2 cents..... Daniel Graversen in response to James Wood on page 8 Oct 9, 2013 6:52 AM Hi James Yes the abap stack is somehting that destingues SAP PI from evertyhing else. And it would probably be treated at a new skill set if it was not SAP branded. Then people would accept that the tool was something new that you must learn, and there was no reason for reusing abap skills. It would though probably be more defficult to get acme pi sold. In my view that abap does not make a lot of improvement in my world for the PI. I guess that ICO objects could have been defiend for ABAP mappings also, if it was on the drawingboard at the time. But I think that the PI get more complext of having the extra layer which just is used to move messages. Thanks for the good comments. Daniel Graversen in response to Michal Krawczyk on page 9 Oct 9, 2013 6:37 AM Hi So if you hooked up a few adapters you would be able to do everything in the AIF. A shame that I'll not be at teched this year. Daniel Daniel Graversen in response to Darryl Griffiths on page 10 Oct 9, 2013 6:34 AM Hi Yes the performance degrade as you put more stuff on, and if you are not sure then you will add unnessary complexity. Like make too many look ups or reduce performance with other easy to maintain functions. Monitoring PI is not a basis job. It is much more complex and different than monitoring a ABAP erp system. There is much differnt things that can go wrong.

Generated by Jive on 2013-12-12+01:00 8

Process Integration (PI) & SOA Middleware: We don't want Java on SAP PI

James Wood Oct 8, 2013 3:23 PM To me, much of this issue is about perception. For some reason, most of the IT organizations I've been around lump all SAP products together in a separate bucket to be maintained by an SAP development team comprised mostly of ABAP developers. In my experience, this is where a lot of pushback on a Java-centric direction of PI comes from. For the average ABAP developer, I expect it's a very scary proposition to be tasked with maintaining a Java-based middleware solution that uses a lot of unfamiliar XML and Web-based protocols. For this reason, I think having an ABAP stack lying around has been something of a security blanket for ABAP developers having to support PI integration scenarios... The irony to me is that many of these organizations have other middleware solutions in house that are treated very differently when compared to PI. Indeed, if you renamed SAP NetWeaver PI as Acme PI, I expect customers would treat the product very differently both from an architecture perspective and a staffing perspective. Ultimately, I think the rub with all this comes down to how you view the positioning of middleware in the landscape. Most middleware tools do a good job of translating between different technical protocols and message schemas. These tasks typically require little business knowledge to carry out. Anything more than that though requires that we collect business rules/data/configuration from various endpoint systems and define BPM processes that must be maintained and monitored in a separate system. In the case of PO, I think a lot of SAP customers have some hesitancy in pulling too much of this over into a Java landscape. Indeed, the development cost alone goes up quite a bit when you think about the investment required to pull the necessary information over into the process definition (both at design time and runtime). So, rather than invest heavily in a solution they don't fully understand/trust, I think the preference for a lot of customers is to go with the devil they know and push the processing down to SAP Business Suite systems, etc. This leads into the positioning of the AIF framework mentioned by Michal above I think. Despite coming from a Java background, I tend to think that SAP made a mistake in developing PO on a Java stack. I think an ABAP-based solution would have been much more well received by the community as a whole. PI certainly makes sense to run on a single stack Java-based architecture, and it's probably not too tough a sell for customers if they have a transparent PO solution which can be monitored/maintained by resources accustomed to working in the ABAP world. In other words, keep the business logic in ABAP and let Java handle the technical details that it excels at - Web protocol handling, XML parsing, etc. My two cents anyway. Good discussion topic Daniel! Michal Krawczyk Oct 8, 2013 2:24 PM hi Daniel,

Generated by Jive on 2013-12-12+01:00 9

Process Integration (PI) & SOA Middleware: We don't want Java on SAP PI

Funny enough AIF (application interface framework) is released by SAP and it's a complete mapping, routing, validation engine written in ABAP (it does not have any apdaters...). I'll be doing expert session roundtables on both techeds on AIF if anyone is interested. Regards, Michal Krawczyk Darryl Griffiths Oct 8, 2013 2:01 PM Hi Daniel, I'm afraid I disagree with you. It starts with a nice new working SAP PI system, but after some time, and many inexperienced fingers, the system performance is not good enough. Maybe the customer's use of PI has changed slightly, or the capacity is no longer sufficient. In this scenario, you need a capable SAP PI administrator. Someone who understands the importance of a correctly configured system (correct for the customer and the customer's current business scenario). It's possible that you can get a consultant to help once in a while, and leave the feeding and watering to ABAP BASIS guys, but there will be that one time, at 3am in the morning, when it stops working. You'll be wishing you had a capable PI guy. I think SAP implemented SAP PI in Java because it uses a lot of open standards, which are developed or rather, easily developed, in Java. It's possible they could make it all work in ABAP, but that would take a lot of effort. Regards, Darryl Ricardo Viana in response to Daniel Graversen on page 11 Oct 8, 2013 12:00 AM I agree with you Daniel.

But I learned to expand my knowledge, but Im not abap developer of reports, exits, enhancements and others hehe.. Also I agree about single stack, I already use the AEX in 2011 its much more better if the SAP PI as middleware layer for simples interfaces. That's it.

Generated by Jive on 2013-12-12+01:00 10

Process Integration (PI) & SOA Middleware: We don't want Java on SAP PI

Regards, R.Viana. Daniel Graversen in response to Ricardo Viana on page 11 Oct 7, 2013 8:27 PM Hi Richardo. If you are a good PI consultant there should not be any reason for you to learn abap. Unless you want to use it for other things. There is pleanty that knows abap and can help you improve rfc, proxys and idocs. It may be a problem that PI is so complex. As you said the single stack makes things a bit simpler, since things can only fail once place and configuration is easier. 95% of all integrations can be done without ccBPM/BPMN, so much of it is quite simple. Daniel Daniel Graversen in response to Iaki Vila on page 12 Oct 7, 2013 8:17 PM It is not all abap programmers how will be java programmers. Though it will probaly not damage them to learn java and OO. Which can help learing abap OO. Yes too much opensource code has been done for the JAVA, and development is much faster than is possible on ABAP . Ricardo Viana Oct 7, 2013 8:08 PM Hi Daniel nice discussing,

Answering your question, my opinion you dont need a SAP PI Developer Certificate or Java developer to maintain the interfaces or check the status at NWA or runtime workbench, as you told the most of interfaces it s with graphical mapping, but its important the Senior SAP PI Consulting do a good and nice faceout (Simple course about - How to develop into PI - Differences between REP/DIR - SLD )with support team than they will be able to maintain the system or chance something when necessary.

Also about Oracle bought Sun its not problem, SAP bought the license of JVM for many many years so with this you can develop something more complex like JavaMapping or Module Adapter, as you can see now tou cant use a JVM from Oracle into NWDS 7.3 you must you JVM SAP.

Im SAP PI developer in Brazil and hear here all time from good and abap experts that they wants to start a SAP PI consulting life, but they don't have any patience to learn about integration patterns, java language and others things.

Generated by Jive on 2013-12-12+01:00 11

Process Integration (PI) & SOA Middleware: We don't want Java on SAP PI

So why I must learn a abap language ? I did course just to know, debugging, programming and check something, why abapers could not do the same with java/Integration and Archtecture patters ?

SAP PI its not a simple tool, there is more behind it that abaps dont have vision sometimes, my option (not all abapers !!!!!! ), you must thing about Architecture perspective, know about type of adapters, integration, SOA, after that select the best way to developer the interface into SAP PI and version of PI. The big mistake that Ive been see here is using SAP PI dual stack but in most of cases its possible to use SAP PI AEX (single javastack) with simples mappings MM that will be much more performace and easy maintain than dual stack..

Another error that its comum here, I define the best way like PROXY interface but when I check the abap code, is calling functions and the abapers don't know how to developer ABAP OO using methods. Do you have this same issue there ? I hear something that SAP is developing the adapters into abap stack, but I think that is something for future. So again my opnion,

See you. Iaki Vila Oct 7, 2013 6:54 PM Hi Daniel, I agree with you that SAP is leaving out the SAP stack dangerously for their echonomical purposes, perhaps in a first view. But, the question is that in the integration world which changes everyday there are java community larger than the ABAP one, with all the changes up to date. The SAP bussines is the ERP, i think tools like PI are only to get a possition in the market with all the necessary stuff developed by SAP, i still remind the Business Connector... It's cheaper to adapt java code to the SAP Netweaver plataform that to develop an ABAP/JAVA architecture forever, when i believe the SAP clients will want always all the software packages from one company avoiding to purchase products to different vendors. I think the java bet is not bad bet for SAP, although the ABAP programmers have to learn Java.

Generated by Jive on 2013-12-12+01:00 12