Options for Interface Pattern Deployment - Technical Whitepaper

Options for Interface Pattern Deployment

April 2013

Overview In today's world, most of the business processes are digitized and clients have good options to deploy best of breed solutions

for their individual requirements. Additionally, external communications such as e-commerce and cloud based solutions

generate need to manage data communications really efficient.

The discrete architecture of different systems and their inter data dependency generates the need for deployment of highly

efficient data communication architecture between the systems. Though most of the third generation systems support open

service oriented architecture, still there is good probability for existence of old legacy systems and their system specific

communication requirements.

The purpose of this technical document is to highlight on the various aspects of interface deployment options using SAP ECC

as origin or destination system and evaluate the use for different system interface architectures in this regard.

Options for Interface Pattern deployment

1. IDOC <-> File/JMS with File delivery or send to/from Affiliate

This pattern can be leveraged when standard ALE interface for information exchange is available from SAP out of box with

capability to enhance IDOC structure and information extraction/population/posting with user exit type enhancements.

Outbound: IDOC -> File/JMS

SAP PI Receive the message from ECC as source structure, and then convert to the target structure as affiliate requirements with

transformation. Finally, SAP PI will send the message to affiliate by file adapter for JMS adapter.

Note: IDOC Packaging is only supported since PI 7.1. Some work around need to be considered in the versions before PI 7.1.

Inbound: File/JMS -> IDOC

SAP PI pick up the source file from the specific folder as sender file channel or sender JMS channel configuration, and then convert

to the IDoc structure with transformation. Finally, SAP PI will send the IDoc to ECC by IDoc adapter.

If you neither need mapping nor content-based routing, you can prevent the IDoc to be converted into IDoc-XML. Of course, this

only makes sense if both your sender and receiver expect the message in IDoc format. This leads to an improved system

performance.

Note: Message Protocol File Content Conversion could be leveraged to process the layout transformation from XML to flat file or

vice versa.

a. Sub-patterns

1. One IDOC to One File/JMS Message:

No IDOC package or split/routing required in this scenario. The IDOC would be posted through PI with some necessary

transformation. No sender channel is required due to sender IDoc adapter is built-in adapter. However, the receiver JMS or file

channel should be configured.

2. One IDOC to Multiple JMS Message:

ECC PI M/W Affiliate System ( s )

IDOC ( s ) ( Packaging Optional )

Sender / Receiver IDOC / FILE

Sender / Receiver JMS

ESR

ID Scenario Queue Applicati on & DB

ABAP Components

File System

One single IDoc from ECC would be delivered to multiple affiliates based on some routing rules in PI. The routing rules would

be defined in receiver determination in Integration Directory of PI. As a plus, message split could be considered in message

mapping to split one message to multiple pieces for various receivers.

3. Multiple IDOCs to One JMS Message:

This pattern supposes to use IDOC packaging to send multiple IDOCs from ECC to affiliate in one message. The overall

approach is variable which depends on the PI version we proposed. In PI 7.1, it supports IDOC packaging in IDOC Sender

Channel.

4. Multiple IDOCs to Multiple JMS Message:

This is a more complicated case and should be a mix-match solution per previous sub-pattern 2 and 3. Generally, by using

IDOC packaging to dispatch the IDOCs from ECC in one message. Using routing condition engine in PI to send messages to

multiple receiver affiliates. As a plus, message split could be considered in message mapping to split one message to multiple

pieces for various receivers.

b. Error Handling

1. Any transformation errors will be caught in the Runtime Workbench by SAP PI. Upon review these errors will be processed

manually.

2. Alert, CCMS, Monitoring Infrastructure could be part of Integration Strategy and Architecture, Possibility of email integration for

alerts.

3. IDOC level Checking will be done by the ALE layer. These errors will result in a workflow email being sent to the appropriate

group that will handle interface errors.

4. For the detail information, please refer to <Exception Handling>

c. Recommendations:

Usually, adopt a generic interfacing approach to SAP systems maintaining high configuration reuse of standard API objects

(BAPI/IDOCs). If there is standard IDoc, or enhancement the IDoc after some change in ECC, which can be included the data as

affiliate need. Otherwise, we can use proxy to replace IDoc.

d. Summary

Parameter Details

INPUT IDOC/File

OUTPUT JMS Message

MAX RECCOMENDED MESSAGE SIZE 40 MB

FILENAMING REQUIREMENTS N/A

FIFO Supported fully with specific configurations

PROTOCOLS SUPPORTED NSF, FTP, JMS, tRFC

2. File<->File Interface

This pattern enables you to exchange data with the Integration Server or the PCK by means of a file interface or an FTP server.

Transformation: Mappings (Graphical, ABAP, XSLT or Java) can be leveraged to convert source format into the format required by

affiliate system or vice versa.

Outbound: File -> File

SAP PI picks up the source file generated by custom ABAP program from ECC as sender file channel configuration, and then

converts to the target structure with transformation. Finally, SAP PI will write the file to the target folder or FTP server.

Note: This pattern could be used to transfer a large file to affiliate by using ABAP Map. On PI 7.3, the capabilities to copy very large

files between locations (file share, FTP) are enhanced and the chunks are merged on the receiver side.

Inbound: File -> File

SAP PI pick up the source file from affiliate as sender file channel configuration, and then convert to the target structure with

transformation. Finally, SAP PI will write the file to the target folder which will be processed by custom ABAP program.

Note: For this case, there should be monitoring utility involved to inform that there is new file waiting for ECC program.

ECC PI M/W Affiliate System ( s )

Report Sender / Receiver File Sender / Receiver

File

ESR

ID Scenario Queue Applicati on & DB

ABAP Components

File System

a. Sub-patterns

1. Normal file to file scenario:

Source file is picked up as sender channel configuration, and then posted through PI with some necessary transformation as

receiver channel configuration.

Note: For inbound case, there should be monitoring utility involved to inform that there is new file waiting for run by the ECC

program.

2. Large file wrap to affiliate

The real data file never should be loaded into PI adapter. Use trigger file (.rdy) that contains the real file name and RID details

for ECC generated data file. File channel will pick up .rdy file and send to ABAP Map. ABAP Map will read .rdy file and wrap the

data file to affiliate.

3. Large (Binary) File-To-File Transfer (Only support on PI 7.3)

There is big improvement on PI 7.3 during large data transfer. The file can be transferred by many chunks, and the chunks are

merged on the receiver side.

b. Error Handling


manually. 2. Alert, CCMS, Monitoring Infrastructure could be part of Integration Strategy and Architecture, Possibility of email integration for

alerts.

3. For the detail information, please refer to <Exception Handling>.

c. Recommendations

Usually, adopt a generic interfacing approach to transfer large file.

d. Summary

Parameter Details

INPUT File

OUTPUT File

MAX RECCOMENDED MESSAGE SIZE No restriction



PROTOCOLS SUPPORTED NSF, FTP

3. Proxy <-> File/JMS Interface

This pattern can be leveraged those cases which can't find the standard IDoc type or have special application logic out of SAP. Proxy

process the Mapping and rooting on Integration Engine bypass Adapter Engine, so it will improve the performance, also, it supports

acknowledgements and could be used to control Application, System Error.

Transformation: Mappings (Graphical, ABAP, XSLT or Java) can be leveraged to convert XML Message in to the format required by

affiliate system or vice versa.

Proxy generation enables you to create proxies in application systems. Proxies encapsulate the creation or parsing of XML messages

and the communication with the relevant runtime components required to send or receive the messages. In proxies, we could write

complicated mapping logic in application which helps to improve the performance of PI.

Outbound: Proxy -> File/JMS


transformation. Finally, SAP PI will send the message to affiliate by file adapter for JMS adapter, it is not necessary to do any

sender adapter configurations when using proxies.

Inbound: Proxy <- File/JMS

SAP PI pick up the source file from the specific folder as sender file channel or sender JMS channel configuration, and then convert

to the XML structure with transformation. Finally, SAP PI will send the XML Message to ECC by XI adapter.

Note: Message Protocol File Content Conversion could be leveraged to process the layout transformation from XML to flat file or

vice versa.

a. Sub-patterns

1. Message splitting

ECC PI M/W Affiliate System(s)

ReportSender/Receiver File

Sender/ReceiverFile

ESR

ID Scenario QueueApplication & DB

ABAP Components

File System

For outbound scenario, we could control the message splitting by ABAP code in the application systems. As a plus, message

split could be considered in message mapping to split one message to multiple pieces for various receivers.

2. Synchronous communication/Acknowledgment confirms

Using Proxy, it could be used for synchronous or asynchronous scenario, but for JMS and File only support asynchronous

communication. If there is a requirement on synchronous, we could create both sender channel & receiver channel and add

additional modules.

For file adapter, it could send back a synchronous system acknowledgement if the sender requests it. The acknowledgment

confirms that the message was delivered to the receiver.

3. The proxy would be posted through PI with some necessary transformation. No sender channel is required due to sender proxy

adapter is built-in adapter. But for receiver channel configuration is required.

b. Error Handling


manually.

2. Alert, CCMS, Monitoring Infrastructure could be part of Integration Strategy and Architecture.

3. If the scenario is inbound asynchronous interface, we could use FEH to do the error handling


c. Recommendations

For the business transaction or master data, if there is no corresponding IDocs, we would use proxy to replace IDoc. Also for some

scenarios which need synchronous communication, we would use this pattern.

d. Summary

Parameter Details

Outbound Proxy -> File/JMS

INPUT File/XML Message

OUTPUT JMS Message

Inbound Proxy <- File/JMS

INPUT JMS Message

OUTPUT File/XML Message




PROTOCOLS SUPPORTED NSF, FTP, JMS, HTTP

4. Proxy <-> Web Service Interface

The proxy runtime options are different depending on the implementation language. There are ABAP Proxy and Java Proxy, Proxy in this

document means ABAP Proxy. There are two different uses for the ABAP proxy runtime:

• Want to exchange messages with the Integration Server by using ABAP proxies. To send a message to the Integration Server, use a

consumer proxy. To provide a service on the SAP Web AS that can be addressed by messages from the Integration Server, use a

provider proxy

• Want to call a Web service in the Internet and have generated a consumer proxy for this purpose. Refer to pattern Web Services <-

>Web Service.

If suitable external web service already exists or easy to create, while ECC has no standard IDOC/RFC interface but can easily define a XML

structure interface, it is convenient to implement Proxy to Web Service pattern. Configuration needs Web Service URL link or WSDL file, and

in ECC, need generate proxy class for ESR interface and additional ABAP logic to call or implement the proxy method.

Transformation: Mappings (Graphical, ABAP, XSLT or Java) can be leveraged to convert Message XML in to the format required by affiliate

system or vice versa.

Outbound: Proxy -> Web Service

SAP ECC acts as the web service consumer and sends XML message to web service provider of other system to call function or get

information needed back. In PI ESR need create outbound interface; in PI ID need create receiver communication channel for web service

call; in ECC need generate proxy class for ESR outbound interface, and create program or use enhancement to call the proxy method.

ECC PI Service Provider Affiliate System(s)

Client Proxy WS adapter

ESR

ID Scenario Web ServiceApplication & DB

ABAP Components

Inbound: Proxy <- Web Service

SAP ECC acts as the web service provider and wraps SAP RFC function / BAPI, other system can access these functions by calling

web service. ECC needs generate service provider based on specific RFC function / BAPI.

a. Sub-patterns

1. Message splitting

For outbound scenario, we could control the message splitting by ABAP code in the application systems. As a plus, message

split could be considered in message mapping to split one message to multiple pieces for various receivers.

2. Guaranteeing process exactly once in order

In the case of asynchronous communication from proxy to web service, there may be requirement to ensure the messages

being processed in the same order as they were sent from the ECC. To achieve this, need additional code to specify the queue

name in ECC program before it's calling proxy method.

b. Error Handling


manually.

2. WS adapter error needs to be checked in PI adapter monitoring.

3. For the detail information, please ref to <Exception Handling>.

c. Recommendations

This pattern is suitable when appropriate user-defined web service or SAP-delivered web service already exists. And to decide

whether or not using PI, that depends on specific situations. Basically if performance is the main concern, like massive messages

processing, recommend using direct communication; while if only single message to be processed, and also particular PI routing

and mapping functions need to use, recommend using communication with PI integration server.

d. Summary

Parameter Details

INPUT ABAP program internal data

OUTPUT SOAP XML message




PROTOCOLS SUPPORTED HTTP,SOAP

5. RFC <-> Web Service Interface

If there is the suitable RFC in ECC side and the suitable web service already exists or is easy to define in affiliate, it is convenient to

implement RFC to Web Service pattern. For SAP PI implementation, RFC should be imported to ESR from ECC and Web Service Endpoint

and action or WSDL file should be provided by affiliate.

Note: If you want to call a Web service based on the RFC in the Internet, please refer to pattern Web Services <->Web Service.

ECC PI SOA Gateway Affiliate System(s)

RFC RequestSender/Receiver RFC

Sender/Receiver SOAP

ESR

ID ScenarioApplicatioN

Process

ABAP Components

Pass Through



RFC adapter enables you to use the functions of the Integration Engine or the PCK in existing SAP landscapes. It is used by SAP systems to

connect to the Integration Engine or the PCK by using the RFC interface.

Outbound: RFC -> Web Service

SAP PI receives the message from ECC through RFC, and sends XML message to web service provider of the affiliate to call function or get

response from affiliate.

Inbound: RFC <- Web Service

Affiliate calls the web service provided by SAP PI, and then SAP PI transfers the message to SAP ECC through RFC and sends response

back to affiliate.

a. Sub-patterns

1. Communication using SAP PI integration server

For outbound, RFC should be imported to ESR, and the correct parameter of receiver soap channel should be configured

according to the web service endpoint and action.

For inbound, RFC should be imported to ESR, and SAP PI should create own web service based on the outbound service

interface definition.

This pattern has benefit of being able to use some SAP PI specific functions, like dynamic receiver determination, XML

message mapping, monitoring.

b. Error Handling


manually.

2. Alert, CCMS, Monitoring Infrastructure could be part of Integration Strategy and Architecture, Possibility of email integration for

alerts


c. Recommendations

This pattern is suitable when appropriate user-defined web service or SAP-delivered web service already exists. There should be

existing RFC in ECC. It depends on specific situations to decide on if there is PI involved. Basically if performance is the main

concern, like massive messages processing, recommend using direct communication; while if only single message to be processed,

and also particular PI routing and mapping functions need to use, recommend using communication with PI.

d. Summary

Parameter Details

INPUT R

OUTPUT Soap XML message




PROTOCOLS SUPPORTED sRFCs/tRFCs, SOAP

6. Web Service <->File/JMS Interface

If the suitable that the web service already exists or is easy to define in affiliate and the request or response would be file, it is convenient to

implement this pattern.




Proxy/RFC Sender/ReceiverSOAP

Sender/Receiver File/JMS

ESR


ABAP Components

File System

Outbound: Web Service -> File/JMS

ECC send request to SAP PI Web service, and SAP PI Receive the message from ECC, and then convert to the target structure as

affiliate requirements with transformation. Finally, SAP PI will send the message to affiliate by file adapter for JMS adapter.

Inbound: Web Service <- File/JMS

SAP PI picks up the source file from the specific folder as sender file channel or sender JMS channel configuration, and then

converts to the XML structure with transformation. Finally, SAP PI sends request to ECC web service, and then reverts back the

response to affiliate.

Note: As File and JMS channel don't support synchronize model, we should create both sender channel & receiver channel and add

additional modules.

a. Sub-patterns

1. File/JMS to Web Service

2. For outbound scenario, we should do the additional configuration for sender file or JMS channel.

b. Error Handling


manually.



c. Recommendations

This pattern will suite for the response message with one file as affiliate's requirement.

d. Summary

Parameter Details

Inbound Web service <- File/JMS

INPUT File/JMS Message

OUTPUT Soap XML message




PROTOCOLS SUPPORTED NSF, FTP, JMS, SOAP

7. RFC <-> File/JMS Interface

If the suitable BAPI already exists and the incoming data's validation and check logic could be covered or is easy to define in affiliate and the

request or response would be file, it is convenient to implement this pattern.




Proxy/RFC Sender/ReceiverSOAP

Sender/Receiver File/JMS

ESR


ABAP Components

File System

Outbound: RFC -> File/JMS

SAP PI receives the message from ECC through RFC, and sends XML message to web service provider of the affiliate to call

function or get response from affiliate.

Inbound: RFC <- File/JMS

SAP PI pick up the source file from the specific folder as sender file channel or sender JMS channel configuration, and then SAP PI

transfers the message to SAP ECC through RFC and sends response back to

a. Sub-patterns

1. The following can be considered to use BAPIs with RFC Adapter regarding the interpretation of the execution result and the

commit of the transaction. If it is required that one update BAPI is called, it can be put in a wrapper RFC function module which

first calls this BAPI, does the interpretation of the execution result and than does the commit or rollback of the transaction.

2. If it is required that multiple update BAPIs get committed together within one transaction, these BAPIs can be encapsulated in a

wrapper RFC function module which first calls the BAPIs and at the end does the commit of the transaction depending on their

execution result. In either case the wrapper RFC function module can be called by RFC Adapter.

3. The receiver RFC adapter supports system acknowledgments but not application acknowledgments.

Note: As File and JMS channel don't support synchronize model, we should create both sender channel & receiver channel and add

additional modules.

b. Error Handling


manually.



c. Recommendations

Usually, adopt a generic interfacing approach to SAP systems maintaining high configuration reuse of standard API objects (BAPI).

BAPIs can be implemented as RFC enabled function modules or IDocs. By their nature, RFC function modules are synchronous,

and IDocs are asynchronous. Thus, if the communication should be asynchronous, it is a good idea to use the IDoc implementation

of BAPI.

d. Summary

Parameter Details

Outbound RFC -> File/JMS

INPUT RFC XML

OUTPUT File/XML Message

Inbound RFC <- File/JMS

INPUT File/XML Message

OUTPUT RFC XML




PROTOCOLS SUPPORTED NSF, FTP,JMS, tRFC, sRFC,

8. IDOC/File <-> JDBC Interface

The pattern is applied to need read or write database content with any SQL statement, even stored procedures. It needs database

connection. JDBC (Java Database Connectivity) adapter enables you to connect database systems to the Integration Server or the PCK. The

adapter converts database content to XML messages and the other way around. We could read database content with any SQL statement,

even stored procedures.



We could define a special XML format for content from the Integration Server or the PCK. This format enables SQL INSERT, UPDATE,

SELECT, DELETE, or stored procedure statements to be processed.

ECC PI Affiliate System(s)

IDOC(s)(Packaging Optional) Sender/Receiver

IDOC/FILESender/Receiver

JDBC

ESR

ID ScenarioApplication & DB

ABAP Components

File System

JDBC Driver

Outbound: IDoc/File -> JDBC


transformation. Finally, SAP PI will send the message to affiliate by file adapter for JDBC adapter.

Inbound: IDoc/File <- JDBC

SAP PI receive message from sender JDBC communication channel, and then convert to the IDoc structure with transformation. Finally, SAP

PI will send the IDoc to ECC by IDoc adapter.

a. Sub-patterns

1. There must be exactly one sender agreement for the defined communication channel.

2. The UPDATE statement must alter exactly those data records that have been selected by the SELECT statement. You must

use the same WHERE clause in the UPDATE and the SELECT statements.

3. A message is always processed in exactly one database transaction.

b. Error Handling


manually.



c. Recommendations

The pattern is applied to need read or write database content with any SQL statement which supports JDBC connection.

d. Summary

Parameter Details

Outbound IDoc/File -> JDBC

INPUT File/IDoc Message

OUTPUT JDBC Message

Inbound IDoc/File <- JDBC

INPUT JDBC Message

OUTPUT File/ IDoc Message




PROTOCOLS SUPPORTED NSF, FTP, tRFC, JDBC

9. Web Service <-> Web Service Interface

Usually, two Web Service systems can communication directly, so in some cases, the Web Service call doesn't pass through PI in a

mediated scenario which the messages are sent from sender systems to receiver systems via SAP PI as middleware software providing

process integration services like routing, mapping, and a business process engine. The systems that exchange messages using SAP PI are

separated from each other which make it more flexible to integrate systems of different technologies.

For the scenario that does not pass though PI to receive and forward message, which would help to improve the system performance but

lose loose coupling. As all we already have this case in Phase 1, we will discuss it in sub-patterns.

If the Web Service already exists or is easy to define, it is convenient to implement Web Service to Web Service pattern. Configuration needs

Web Service URL link or WSDL file, and also the consumer proxy class or service provider needs to be generated in SAP ECC.



PI SOA Gateway Affiliate System(s)

Sender/ReceiverSOAP

Sender/ReceiverSOAP

ESR

ID ScenarioApplicatioN

ProcessPass Through

ECC

Consumer/ProviderProxy

ABAP Components

SOA ManagerService Consumer

Outbound: Web Service Consumer (ECC) -> Web Service Provider (External system)

SAP ECC acts as the web service consumer and sends XML message to web service provider of other system to call function or get

information needed back. ECC needs generate consumer proxy based on Web service URL or WSDL file.

Inbound: Web Service Provider (ECC) <- Web Service Consumer (External system)

SAP ECC acts as the web service provider and wraps SAP RFC function / BAPI, other system can access these functions by calling ECC

web service. ECC needs generate service provider based on specific RFC function / BAPI.

a. Sub-patterns

1. Communication using PI integration server

Need to define web service structure, communication channels, and WS consumer and provider system landscape information

in PI.

This pattern has benefit of being able to use some PI specific functions, like dynamic receiver determination, XML message

mapping, PI message monitoring.

2. Communication directly (Point to Point)

For outbound, only need configure web service consumer in ECC SOA manager, then can call proxy class to access web

service; for inbound, only need configure service provider in ECC SOA manager, and provide the web service URL.

In a Point-to-Point scenario, messages are sent directly from a sender system to a receiver system. We would lose the

advantages introduced with the loose coupling of the middleware solution. Furthermore, by bypassing SAP PI during runtime,

we can't use the functionalities and services provided by SAP NetWeaver PI, such as mappings, dynamic receiver

determinations, ccBPM, sending one message to multiple systems, etc.

b. Error Handling


manually.


3. WS adapter error needs to be checked in PI adapter monitoring.

4. Web service consumer or definition errors can be traced in ECC SOA manager.

5. For the detail information, please ref to <Exception Handling>.

c. Recommendations

This pattern is suitable when appropriate user-defined web service or SAP-delivered web service already exists. And to decide

whether or not using PI, that depends on specific situations. We would make the choice between loose coupling and performance.

Basically if performance is the main concern, like massive messages processing, recommend using direct communication. While if

only single message to be processed, and also particular PI routing and mapping functions need to use, recommend using

communication with PI integration server. Also, for integration scenario between Non-SAP systems with SAP PI, we could adopt the

pattern as well.

d. Summary

Parameter Details

INPUT SOAP XML message

OUTPUT SOAP XML message




PROTOCOLS SUPPORTED HTTP,SOAP

Documents

Options for Interface Pattern Deployment - Technical Whitepaper