Using ES instead of a PI based Communication

[Former Member]

Hi,

We have a following scenario.

Source Application ( Legacy ) -

---

PI----

---

SAP ECC ( Via RFC ).

The source application creates a Order, this is picked up by PI which triggers an rfc to create a order in SAP.

Order number generated in SAP is send back to the legacy system.

We were exploring an option of using a Standard ES

SalesOrderERPCreateRequestConfirmation_In_V1

Port Type: SalesOrderERPCreateRequestConfirmation_In_V1

We would like to know:

1. What are the basic advantages of using ES vs PI in the above use case

2. What monitoring tools are available to monitor such service calls.

3. What Error handling mechansims ( like Alerts in PI ) are available for an ES based communication.

Thanks in advance for your help.

Regards,

Abhishek

[Former Member · Accepted solution]

Hi,

>1. What are the basic advantages of using ES vs PI in the above use case

Suggestion is to use ES along with PI so that all other infrastructure benefits offered by PI will be available.

>2. What monitoring tools are available to monitor such service calls.

With standard ES monitoring is still very much premitive so PI combination will be very useful.

>3. What Error handling mechansims ( like Alerts in PI ) are available for an ES based communication.

Not really any mechanism available, you can use combination of tools like trace, ccms, alerts, BAM.

Based on above criteria I'll recommed to replace RFC with ES in your landscape. PI offer centralized place for monitoring which is advantage over ES at this moment.

Regards,

Gourav

[Former Member · Accepted solution]

Hi Gaurav,

Thanks for your reply.

Using ES with PI:

We plan to design the service in ESR and publish the same in the service registry.

We Do not want to use PI runtime here. We would like the legacy application to discover the service and make a direct service call.

The implementation of the service resides in the ECC.

This would make the process adapterless. What's your opinion regarding the same.

[Former Member · Accepted solution]

Hi Abhishek,

If your legacy system is not a user screen, I would not recommend this approach for interfaces which create or modify something.

This approach should be only used for Read operations as you will be unable to manage errors in case of modify operations.

It is better the you expose the web service via PI in this case.

Regards,

Vikas

[Former Member · Accepted solution]

Hi,

>This would make the process adapterless. What's your opinion regarding the same

Certainly it will make process adapterless and it is widely used and pretty common scenario but benefit of mediated processing wont be available i.e. monitoring, alerts etc should be handled out-of-box which is possible by providing proper "fault messages" which can be handled by consumer application (i.e. your legacy application).

If you are using .NET, Java or any other Web Service compliant language then you can consume ES easily like any other webservice.

Regards,

Gourav

[Former Member]

>

> 1. What are the basic advantages of  using ES vs PI in the above use case
> 2. What monitoring tools are available to monitor such service calls.
> 3. What Error handling mechansims ( like Alerts in PI ) are available for an ES based communication.

Hi,

1. In this case the only advantage is that the communication between PI and ECC can be adapter-less. Hence its more efficient.

2. Monitoring can be done using SXMB_MONI. You need to enable logging for synchronous calls.

3. PI alerting capabilities can be used. You can also implement BADI available in the service you mentioned to trigger any emails.

Regards,

Vikas