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
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. 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
FILENAMING REQUIREMENTS N/A
FIFO Supported fully with specific configurations
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
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, 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
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.
3. If the scenario is inbound asynchronous interface, we could use FEH to do the error handling
4. For the detail information, please refer to <Exception 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
MAX RECCOMENDED MESSAGE SIZE 40 MB
FILENAMING REQUIREMENTS N/A
FIFO Supported fully with specific configurations
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
1. Any transformation errors will be caught in the Runtime Workbench by SAP PI. Upon review these errors will be processed
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
MAX RECCOMENDED MESSAGE SIZE 40 MB
FILENAMING REQUIREMENTS N/A
FIFO Supported fully with specific configurations
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
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.
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
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. For the detail information, please refer to <Exception Handling>.
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
MAX RECCOMENDED MESSAGE SIZE 40 MB
FILENAMING REQUIREMENTS N/A
FIFO Supported fully with specific configurations
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.
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.
ECC PI M/W Affiliate System(s)
Proxy/RFC Sender/ReceiverSOAP
Sender/Receiver File/JMS
ESR
ID Scenario QueueApplication & DB
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
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.
3. For the detail information, please refer to <Exception Handling>.
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
MAX RECCOMENDED MESSAGE SIZE 40 MB
FILENAMING REQUIREMENTS N/A
FIFO Supported fully with specific configurations
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.
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.
ECC PI M/W Affiliate System(s)
Proxy/RFC Sender/ReceiverSOAP
Sender/Receiver File/JMS
ESR
ID Scenario QueueApplication & DB
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
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.
3. 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).
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
MAX RECCOMENDED MESSAGE SIZE 40 MB
FILENAMING REQUIREMENTS N/A
FIFO Supported fully with specific configurations
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.
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.
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
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 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
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.
3. For the detail information, please refer to <Exception Handling>.
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
MAX RECCOMENDED MESSAGE SIZE 40 MB
FILENAMING REQUIREMENTS N/A
FIFO Supported fully with specific configurations
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.
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.
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
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.
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
MAX RECCOMENDED MESSAGE SIZE 40 MB
FILENAMING REQUIREMENTS N/A
FIFO Supported fully with specific configurations
PROTOCOLS SUPPORTED HTTP,SOAP