IDocs without PI or Adapter - Part 2

[Former Member]

Hi All,

Following on from my previous question , I have a second question.

What is the best way of finding the address of an IDoc service on ECC?

For instance, I know that SALESORDER_CREATEFROMDAT202 is setup and working on our ECC system. So I would like to experiment with sending text files which obey the relevant schema to this service and see if it accepts it. But how do I find the address of the service?

Thanks in advance for your help. It is appreciated.

Cheers

Gerard

[Former Member · Accepted solution]

HI Gerard,

Id have a look at function modules like;

IDOC_INBOUND_XML_SOAP_HTTP

IDOC_INBOUND_XML_VIA_HTTP

IDOC_XML_FROM_FILE

these may give you the information you are chasing.

Additionally any Remote Enabled FM in ECC can be exposed as a webservice, which would potentially allow you to call the appropriate RM directly.

If creating a PO for example it might be best to ignore the IDOC structures though and go directly to the FM doing the work if this approach is taken, this would avoid all the extra stuff that is involved in IDOCS that are of no use in a webservice call. Elements in the IDOC such as SNDPRT, RCVPRT and so on are of no use if you arent using the SAP EDI/IDOC infrastructure.

[Former Member · Accepted solution]

Hi Richard,

Thanks very much for your reply.

I will look into the function modules you suggested.

We still want to exploit the IDoc infrastructure since it provides good visibility of what has happened to messages. (The users want IDocs used rather than Proxies or web services since IDocs provide better visibility of what's going on.)

I am hoping if that I can simply find the http address of the "IDoc service" then I can simply send a correctly formatted IDoc text file to that. (I have seen documentation to this effect in the past, but am unable to locate it.)

Part 1 of my question has seemed to disappear from the forum. Maybe sending IDocs directly to a http address is not considered best practice.

Thanks again for your reply.

Cheers

Gerard

[Former Member · Accepted solution]

Hi Richard,

My mistake about Part 1 of my question. It is still on the Forum. It just became separated from Part 2.

Cheers

Gerard

[Former Member · Accepted solution]

All services are in SICF, you should be able to find the "IDOC" service there .

We still want to exploit the IDoc infrastructure since it provides good visibility of what has happened to messages. (The users want IDocs used rather than Proxies or web services since IDocs provide better visibility of what's going on.)

I wouldn't have said IDOC provide any real benefit in terms of "visibility". Most users just arent aware of the monitoring transactions to use around proxies, there are also additional benefits around proxies in terms of implementation speed and the ability to create sync. scenario's instead of just IDOC async communication. Throw into the mix the additional configuration required around IDOC setup, Partner profiles and so on.

I think from a interoperability standpoint open standards web services for communication is big step forward towards SOA, webservices exposed for communication can be leveraged by almost any other system moving forward - I think the biggest opportunity in this space is the mobile applications. Getting a mobile application to talk IDOC (possible but potentially problematic), getting a mobile application to talk webservice no matter what platform using any language is best described as simple.

Back to the topic at hand,

I think you will need to use sapjco3.jar and sapidoc3.jar to send an IDOC to ECC from an external source these library's are used by most 3rd party applications to talk to SAP that Im aware of.

I guess you could NOT use them but you would essentially be implementing them yourself.

Good Luck

[Former Member · Accepted solution]

Hi Richard,

I think from a interoperability standpoint open standards web services for communication is big step forward towards SOA, webservices exposed for communication can be leveraged by almost any other system moving forward - I think the biggest opportunity in this space is the mobile applications. Getting a mobile application to talk IDOC (possible but potentially problematic), getting a mobile application to talk webservice no matter what platform using any language is best described as simple.

I agree with this a million percent. I argued that we use Web Services while we wait for full SOA.

Funny thing is that we will be intalling the relevant service packs and going to SOA in a month or so, but I have some things to get started on now. (I hope later to migrate this to SOA.)

I expect you are right. I will probably end up using JCO. I have wanted to avoid this.

(The crazy thing is that I know I have seen documentation on how to do it with just Idoc setup and http calls, but I cannot locate it. So it looks like JCO will be the path.)

Nice to hear from you.

All the best,

Gerard

[Former Member · Accepted solution]

Just for a last thought for anyone reading this post as much as anything else.

At a high level or architectural standpoint the use of an integration engine in these types of scenario's cannot be understated. Regardless of which system is used be it SAP PI, WebMethods or some other technology is crucial for many reasons some of them listed below off the top of my head;

1. Security - allow direct access to your ECC/CRM system is dangerous. Access to a subsystem/integration engine with its associated security libs around services is ideal.

2. Scale up and out - Far more cost effective to have a integration engine double in size then your entire infrastructure.

3. Transactional/Transformation load - better this is pushed onto a another system - crashing SAP PI by somehow overloading it is bad, crashing ECC/CRM will effectively stop everything. Even its not a crash just a slowing over the system due to a influx of messages being able to or limiting the impact on users of the system by controlling/dealing with it in PI is a far better situation than hurting ECC with this stuff.

[Former Member · Accepted solution]

Hi Richard,

Again we are in complete agreement. We would always use an Integration for the reasons you explained.

We have two integration engines - PI and Oracle Service Bus. I am reviewing the advantages of each in this instance. Each has various pros and cons.

A big advantage of PI in this instance is its effortless integration with IDocs.

But PI has problems with large volumes of transactions and using ccBPM for even simple tasks is time consuming etc.

So I was trying to guage just how easy/hard it can be sending IDocs from a system like Oracle Service bus. From the imformation I had it should be very easy - however this does not seem to be panning out.

Probably how productive JCO is will be an important factor.

Cheers

Gerard

[Former Member · Accepted solution]

As part of your analysis Id be looking at the more current implementations of PI or more specifically PO (Java Stack only) and I guess the same goes for Oracle Service Bus, but given this is an SAP forum ....

There has been a few case studies recently

1. ccBPM doesnt exist anymore - its now a pure Java implementation and is much faster (I have not had personal experience with aspect as yet).

2. The integration engine is faster (much), case studies have been talking about 3 times the message volume compared to the traditional PI dual stack. (again, I cant confirm nor deny)

3. Simpler to manage and monitor

Check this blog by