8/13/2019 We Dont Want Java on Sap Pi
1/12
Generated by Jive on 2013-12-12+01:00
1
Process Integration (PI) & SOA Middleware:We don't want Java on SAP PI
Posted by Daniel GraversenOct 7, 2013I 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.
http://scn.sap.com/community/pi-and-soa-middleware/blog/tags#/?tags=javahttp://scn.sap.com/community/pi-and-soa-middleware/blog/tags#/?tags=sapmentorhttp://scn.sap.com/community/pi-and-soa-middleware/blog/tags#/?tags=sap_netweaver_process_orchestrationhttp://scn.sap.com/community/pi-and-soa-middleware/blog/tags#/?tags=process_integrationhttp://scn.sap.com/people/daniel.graversenhttp://scn.sap.com/people/eduardo.chiocconihttp://scn.sap.com/people/eduardo.chiocconihttp://scn.sap.com/community/pi-and-soa-middleware/blog/tags#/?tags=pi_7.31http://scn.sap.com/community/pi-and-soa-middleware/blog/tags#/?tags=pohttp://scn.sap.com/community/pi-and-soa-middleware/blog/tags#/?tags=pi_731http://scn.sap.com/community/pi-and-soa-middleware/blog/tags#/?tags=architecturehttp://scn.sap.com/community/pi-and-soa-middleware/blog/tags#/?tags=videohttp://scn.sap.com/community/pi-and-soa-middleware/blog/tags#/?tags=abaphttp://scn.sap.com/community/pi-and-soa-middleware/blog/tags#/?tags=process_integrationhttp://scn.sap.com/community/pi-and-soa-middleware/blog/tags#/?tags=sap_netweaver_process_orchestrationhttp://scn.sap.com/community/pi-and-soa-middleware/blog/tags#/?tags=sapmentorhttp://scn.sap.com/community/pi-and-soa-middleware/blog/tags#/?tags=javahttp://scn.sap.com/people/daniel.graversen8/13/2019 We Dont Want Java on Sap Pi
2/12
Process Integration (PI) & SOA Middleware: We don't want Java on SAP PI
Generated by Jive on 2013-12-12+01:00
2
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 theoption of bothJava 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 communitybetter. 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 Senin response to Anupam Ghoshon 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 Graversenin response to Suseelan Harion page 4
Nov 3, 2013 5:41 AM
http://scn.sap.com/people/daniel.graversenhttp://scn.sap.com/people/nabendu.senhttp://scn.sap.com/people/daniel.graversenhttp://scn.sap.com/people/daniel.graversenhttp://scn.sap.com/people/nabendu.senhttp://scn.sap.com/people/nabendu.sen8/13/2019 We Dont Want Java on Sap Pi
3/12
Process Integration (PI) & SOA Middleware: We don't want Java on SAP PI
Generated by Jive on 2013-12-12+01:00
3
Yes it is amazin how many like the topic and want to share their comments..
Daniel Graversenin response to PEDRO DOMINGUES PEREIRAon 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 Graversenin response to Carlos Ivan Prieto Rubioon 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 !!!
http://scn.sap.com/people/carlosivan.prietorubiohttp://scn.sap.com/people/carlosivan.prietorubiohttp://scn.sap.com/people/daniel.graversenhttp://scn.sap.com/people/daniel.graversenhttp://scn.sap.com/people/daniel.graversenhttp://scn.sap.com/people/daniel.graversen8/13/2019 We Dont Want Java on Sap Pi
4/12
Process Integration (PI) & SOA Middleware: We don't want Java on SAP PI
Generated by Jive on 2013-12-12+01:00
4
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 Ghoshin response to Nabendu Senon 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
http://scn.sap.com/people/harisuseelanhttp://scn.sap.com/people/nabendu.senhttp://scn.sap.com/people/nabendu.senhttp://scn.sap.com/people/harisuseelanhttp://scn.sap.com/people/harisuseelanhttp://scn.sap.com/people/anupam.ghosh2http://scn.sap.com/people/anupam.ghosh2http://scn.sap.com/people/pedro.dominguespereirahttp://scn.sap.com/people/pedro.dominguespereira8/13/2019 We Dont Want Java on Sap Pi
5/12
Process Integration (PI) & SOA Middleware: We don't want Java on SAP PI
Generated by Jive on 2013-12-12+01:00
5
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 Woodin response to Anupam Ghoshon page 5
Oct 18, 2013 2:14 AMABAP 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 Ghoshin response to Daniel Graversenon 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 havingsense 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
https://scn.sap.com/thread/1983926http://scn.sap.com/people/anupam.ghosh2http://scn.sap.com/people/anupam.ghosh2http://scn.sap.com/people/james.woodhttp://scn.sap.com/people/james.wood8/13/2019 We Dont Want Java on Sap Pi
6/12
Process Integration (PI) & SOA Middleware: We don't want Java on SAP PI
Generated by Jive on 2013-12-12+01:00
6
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. Bothrequired and not required functionswill get loadedonce user logs in.
Maybe I am used to coding, hence supporting it but all this is my personal opinion and respect yours too.
Daniel Graversenin response to Anupam Ghoshon 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 PMHi 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 Woodin response to Daniel Graversenon page 6Oct 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 Graversenin response to James Woodon 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 italternated between java and abap only solutions. But we have a much different level of manturity
on the product now.
Daniel Graversenin response to Stefan Hilppon page 7
Oct 11, 2013 12:21 PM
http://scn.sap.com/people/daniel.graversenhttp://wiki.scn.sap.com/wiki/display/ABAP/Zip+any+file+via+ABAP+using+CL_ABAP_ZIPhttp://scn.sap.com/people/daniel.graversenhttp://scn.sap.com/people/daniel.graversenhttp://scn.sap.com/people/daniel.graversenhttp://scn.sap.com/people/daniel.graversenhttp://scn.sap.com/people/daniel.graversenhttp://scn.sap.com/people/james.woodhttp://scn.sap.com/people/james.woodhttp://scn.sap.com/people/anupam.ghosh2http://scn.sap.com/people/anupam.ghosh2http://wiki.scn.sap.com/wiki/display/ABAP/Zip+any+file+via+ABAP+using+CL_ABAP_ZIPhttp://scn.sap.com/people/daniel.graversenhttp://scn.sap.com/people/daniel.graversen8/13/2019 We Dont Want Java on Sap Pi
7/12
Process Integration (PI) & SOA Middleware: We don't want Java on SAP PI
Generated by Jive on 2013-12-12+01:00
7
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 indifferent 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 Woodin response to Stefan Hilppon 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 allEDI-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 ;-) )
http://scn.sap.com/people/stefan.hilpphttp://scn.sap.com/people/stefan.hilpphttp://scn.sap.com/people/stefan.hilpphttp://scn.sap.com/people/james.woodhttp://scn.sap.com/people/james.wood8/13/2019 We Dont Want Java on Sap Pi
8/12
Process Integration (PI) & SOA Middleware: We don't want Java on SAP PI
Generated by Jive on 2013-12-12+01:00
8
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 Graversenin response to James Woodon 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 Graversenin response to Michal Krawczykon 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 Graversenin response to Darryl Griffithson page 10Oct 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.
http://scn.sap.com/people/daniel.graversenhttp://scn.sap.com/people/daniel.graversenhttp://scn.sap.com/people/daniel.graversenhttp://scn.sap.com/people/daniel.graversenhttp://scn.sap.com/people/daniel.graversenhttp://scn.sap.com/people/daniel.graversenhttp://scn.sap.com/people/barry.neaves3http://scn.sap.com/people/barry.neaves38/13/2019 We Dont Want Java on Sap Pi
9/12
Process Integration (PI) & SOA Middleware: We don't want Java on SAP PI
Generated by Jive on 2013-12-12+01:00
9
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 PIas 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 ifthey 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,
http://scn.sap.com/people/michal.krawczyk2http://scn.sap.com/people/michal.krawczyk2http://scn.sap.com/people/james.woodhttp://scn.sap.com/people/james.wood8/13/2019 We Dont Want Java on Sap Pi
10/12
Process Integration (PI) & SOA Middleware: We don't want Java on SAP PI
Generated by Jive on 2013-12-12+01:00
10
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 Vianain response to Daniel Graversenon 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.
http://scn.sap.com/people/ricardo.vianahttp://scn.sap.com/people/ricardo.vianahttp://scn.sap.com/people/darryl.griffithshttp://scn.sap.com/people/darryl.griffiths8/13/2019 We Dont Want Java on Sap Pi
11/12
Process Integration (PI) & SOA Middleware: We don't want Java on SAP PI
Generated by Jive on 2013-12-12+01:00
11
Regards,
R.Viana.
Daniel Graversenin response to Ricardo Vianaon 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 Graversenin response to Iaki Vilaon 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 intoPI - 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 withthis 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.
http://scn.sap.com/people/ricardo.vianahttp://scn.sap.com/people/daniel.graversenhttp://scn.sap.com/people/ricardo.vianahttp://scn.sap.com/people/ricardo.vianahttp://scn.sap.com/people/daniel.graversenhttp://scn.sap.com/people/daniel.graversenhttp://scn.sap.com/people/daniel.graversenhttp://scn.sap.com/people/daniel.graversen8/13/2019 We Dont Want Java on Sap Pi
12/12
Process Integration (PI) & SOA Middleware: We don't want Java on SAP PI
Generated by Jive on 2013-12-12+01:00
12
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.
http://scn.sap.com/people/iaki.vilahttp://scn.sap.com/people/iaki.vila