B2B vs A2X vs A2A

[Former Member]

Hi.

We are looking at the ES workplace to find the correct operation to use to create a Sales order in our backend:

http://esworkplace.sap.com/socoview(bD1lbiZjPTAwMSZkPW1pbg==)/render.asp?id=C3D3B294081411DA1503000B...

There are two entries available.

One for Category A2X (Manage Sales Order In) called SalesOrderCreateRequestConfirmation_In.

And then one for Category B2B (Ordering in) called PurchaseOrderRequest_In.

Does this mean that we would have two Services in our Services catalog configured?

One for B2B type communication and one for A2X communication?

What is the main difference between the two though?

Many thanks if you can help.

Rodney

[former_member220741]

Hi,

Please refer to the following sap online help.

http://help.sap.com/saphelp_nwpi71/helpdata/en/de/24e604d01b4504898084af80e24f33/content.htm?framese....

Essentially the concept is A2X service is for UI consumption, synchronous accesses and normally user get error message right away if something wrong, and you should be able to consume these service directly if you want.

While A2A or B2B process, in major case, will include forward error handling etc and need involve EAI/ESB middleware, in this case, most likely SAP PI.

While may not be accurate, I view A2X as a RFC call, and B2B  service as EDI/IDoc in more tranditional world. Backt to your question, yes, these are two entries in ESR, and likewise, you will have two entries in your Enterprise Registry

--Wenning

[Former Member]

Thanks Wenning.

This makes sense. I like the analogy to the more "traditional world"...

I suppose you could also use a A2X service in a A2A or even B2B way, if the calling appliation can handled it and the middleware layer is quick enough.

The reason I ask this is that sometimes we get a request from our EDI partner to setup a "lightweight" synchronous B2B service. We then use the A2X service.

Your thoughts?

Rod

[former_member220741]

Hi, Rod,

Yes, I believe I am less hesitated to use A2X for A2A usage, but maybe need more thought and justification for B2B.

Functional wise,surely you can create a SAP sales documents by A2X service call, but for external access, I will not recommend you put ECC web service directly on to internet, even just for potential perfromance concern. And if we do not allow direct ECC call, instead of using broker, like SAP PI . since you will need broker or ESB anyway,  maybe it is just easier for you to simplify SAP ES web service into a more lightweight schema and design you own service. You can add mapping logic, validation etc also.

Even that, in your example, it is your sales order, I will say I will guide the partners to use EDI or Asynchronous request/confirmation pattern, instead of synchronous call. In case error happens, instead of bouncing back error as synchronous repsonse, maybe your sales person can login the system, and forward error hadnling it. Again, it is case dependent, I do not see any black and white,  just need more justification to see what fit you better.

--Wenning

[Dimitri]

Hi Rodney,

Have a look which data/parameters you need to provide to your back end system in order to create a SO.

Next, have a look at both Service Interfaces and decide which one best suits your needs and meets your requirements. There is no need to have them both configured and used.

The category is just an indication SAP gave to it. To quickly find back relevant information.

Kind regards,

Dimitri

[Former Member]

Hi Dimitri.

The data to be sent in the two services differ significantly. The B2B interface has a lot more information to be sent.

I found some use case when to use what, here:

http://wiki.scn.sap.com/wiki/display/ESpackages/Order+to+Cash

Our current thoughts are to publish both to our Enterprise Registry, but we might only publish as the requirement comes along.

Its still a bit hazy but thanks for the response.

Rod

[Dimitri]

Hi Rodney,

That is indeed also an option.

Just make sure they are both available and decide afterwards which one is best to meet your requirements.

Kind regards,

Dimitri