We Dont Want Java on Sap Pi

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.graversen


2/12

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


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.sen


3/12



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.graversen


4/12



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.dominguespereira


5/12



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.wood


6/12



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.graversen


7/12



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.wood


8/12



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.neaves3


9/12



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.wood


10/12



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.griffiths


11/12



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.graversen


12/12



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

Documents

We Dont Want Java on Sap Pi