This blog will provide a general understanding of bridges in SAP PO with a business use case. Additionally, we will explore the different types of bridges with examples.
To put it plainly, underneath is the substance we will be intricate in this instructional exercise:
- What is a Bridge in SAP PO?
- Async-Sync Bridge Scenarios
- Sync-Async Bridge Scenarios
1. What is a Bridges in SAP PO?
Say, you are sending data from an async framework (Document) to outer framework (Web-administration/RFC – Sync). The beneficiary can return reaction message, however source is offbeat. Subsequently, the association from source side will be shut whenever it is sent, as it is nonconcurrent.
There are two types of bridges:
1. Async – Sync Bridge
2. Sync – Async Bridge
Two answers for these issues:
- Utilizing ccBPM/BPM
- Utilizing standard connector modules
Using ccBPM/BPM:
Advantage:
- Complex cycles with various frameworks
Disadvantage:
- Improvement and testing time.
- Observing and investigating intense
- ccBPM not accessible in Single stack establishment, subsequently BPM should be utilized.
Using standard adapter modules:
Advantage:
- Simple observing and troubleshooting, testing, creating
Disadvantage:
- Clear comprehension of module boundaries required. Could get confounded.
2. Async – Sync Bridge Scenarios:
Scenario:
Record will be shipped off PI and message change/planning will happen, post that, message will be communicated to RFC which is a simultaneous BAPI made in ECC which returns reaction, and it will be put away in a Document.
Adapters – Sender File, Receiver RFC, and Receiver File
- Source framework – Async
- Recipient framework – Sync
- Thus, sending a solicitation and getting reaction in the source connector/channel will be two free errands.
- Target framework, as it is sync, will send reaction in which the solicitation came.
Connector modules to be utilized in Shipper Correspondence Channel:
- RequestResponseBean – Converts Async message to Match up message and moves it to next module chain.
- ResponseOnewayBean – Converts Sync message to Async message and diverts it to beneficiary.
| MODULE NAME | TYPE | MODULE KEY |
| AF_Modules/RequestResponseBean | Local Enterprise Bean | Req |
| CallSAPAdapter | Local Enterprise Bean | sap |
| AF_Modules/ResponseOnewayBean | Local Enterprise Bean | Resp |
Boundaries for RequestResponseBean (in Source CC):
passthrough – Valid (Next module in the chain)/Bogus (PI message handling subsystem) – Default (Misleading)
timeout – Response holding up time (in ms) – Default 300000ms
Parameters for ResponseOnewayBean (in Sender CC):
receiverParty/receiverService – Name of comm. Component/Party – Optional
receiverChannel – Receiver Comm. Channel name – Optional
adapterType (FILE)/adapterNamespace (http://sap.com/xi/XI/System) – type and namespace of connector to associate with beneficiary framework – Discretionary.
HANDLING ERROR SCENARIOS:
receiverChannelOnFault – Communication Channel name to receive error messages
replaceInterfaceOnFault – true -> change interface and namespace
false -> keep original interface provided earlier
interfaceOnFault / interfaceNamespaceOnFault
Steps in processing:
- Getting async message from source framework – > Module RequestResponseBean
-> module changes the message type from async to adjust by changing the message header.
- In view of the boundary Passthrough Valid, module passes the message to next module chain, in the event that Misleading, it will skirt the following module chain and straightforwardly goes through informing framework.
- Next is CALL SAP Connector (standard) module, moving it to PI informing framework.
- Sending a solicitation to match up correspondence channel.
- Coordinated call to the outside framework, getting the reaction.
- Getting reaction from sync correspondence channel.
- Return reaction to ResponseOnewayBean changing the message type from sync to async and deciding the recipient framework which is set in MODULE Boundaries.
- Sending reaction to channel.
- Conveyance of message to source framework as async correspondence.
Note:
SAME MODULES Boundaries CAN BE Utilized IN Recipient Correspondence CHANNEL, In the event that YOU Can’t DO IT IN Shipper Correspondence CHANNEL.
3. Sync – Async Bridge Scenarios:
Sender – Sync
Receiver – Async
Modules to be used:
RequestOnewayBean – Converts sync messages to async messages
WaitResponseBean – leaves sync comm channel OPEN and waits for the response. Upon receiving response from async system, it will convert it to SYNC and send it to original system. If no response came, then error message is returned.
NotifyResponseBean – this module used instead of standard adapter module in response async sender channel to transfer the response message directly to WaitResponseBean
——————-
WE HAVE AN ISSUE HERE:
Envision that few messages are going through the extension all the while. Along these lines, eventually couple of questions are sitting tight for reactions. Some reaction is coming from the objective framework – yet the way that we know which of forthcoming channels should be utilized to send a particular response?
CORRELATION ID – this is the saviour
It is the identifier/key, which holds the special worth between reaction message and the anticipating demands.
THE SOLUTION SHOULD BE:
While communicating the solicitation message, some novel identifier that ought to be recalled by the solicitation message and check this identifier with the got reaction message.
We can involve MessageID for this, which is extraordinary for each message. For getting this messageID we can help it through another standard module – > DynamicConfigurationBean
Steps in processing:
- Getting a sync message from outer framework, sending it to RequestOnewayBean which converts message type from sync to async.
- In the event that passThrough is set to Valid, module passes it to next chain of modules.
Else, module passes it to informing framework.
- Standard connector module moves it to PI informing framework.
- Demand moved to async recipient channel
- Async call to outside framework
- Async reaction to source comm channel from outside framework
- Return the reaction to NotifyResponseBean, which sends the async reaction message to WaitResponseBean.
- WaitResponseBean changes over async reaction message to match up reaction message and sends to source framework.
Parameters for RequestOnewayBean (in Sender CC):
passthrough – True (Next module in the chain) /False (PI message processing subsystem) – Default (False)
Parameters for WaitResponseBean (in Sender CC):
timeout – Response waiting time (in ms) – Default 300000ms
Parameters for NotifyResponseBean (in response Sender CC):
timeout – Response waiting time (in ms) – Default 300000ms
fault – Name of an error message
faultNamespace – Namespace of an error message
Next is solicitation and reaction relationship.
We should send messageID in the solicitation message header and pass it to target framework. In returning the reaction, we should fill the correlationID in the reaction header.
This is the manner by which we can deal with the solicitation and reaction of a sync to async span situation. Trust you enjoyed it. On the off chance that you feel somewhat doubtful, inquiries or ideas for us, kindly put your remarks underneath.
YOU MAY BE INTERESTED IN
ABAP on SAP HANA. Part III. Debugging in ADT
Building Cloud-Native ABAP Applications: A Guide to Modern SAP Development
SAP ABAP future in next coming years
WhatsApp us