- SAP Managed Tags:
There are customers who are not yet ready to move fully to cloud so they opt for Hybrid model where some HR modules remain on-premise and some modules are implemented in SuccessFactors (SF). In this case some customers may initially opt to have all integrations from on-premise ECC system rather than from SF EC.
We know that SAP has given an option of SAP Cloud Connector (SCC) to connect on-premise and cloud systems securely which acts as a reverse invoke proxy but there are customers who are yet not convinced with it and want to rely on their on-premise middleware as entry-point into their SAP HR on-premise system.
In such case, customer installs the SCC in their DMZ and also use SAP PI as entry point to their SAP system.
Note: In this case SAP PI doesn't alter the message contents, instead it just passes the message as it is. One important point to note here is that SAP PI changes the message id so you need to find the old and new message ID in your SAP PI system to monitor the messages.
The landscape which is required to support this is shown below.
SAP has given a provision to support this architecture where SAP PI/PO is a passthrough.
Please refer the replication guide from sap.help.com to understand the technical aspects like Transaction codes, programs, web services etc in SAP on-premise which are involved to support the replication.
Sequence of steps is given below.
Note: Sap Cloud Connector is used only for inbound messages to SAP on-premise but not outbound messages.
Adding one more middleware in the replication adds more complexity and creates dependency in case one fails the complete replication will also fail.
Most of the customers prefer to install SCC and use SAP CPI as shown below which is much simpler and mostly followed approach.
We know that SAP has given an option of SAP Cloud Connector (SCC) to connect on-premise and cloud systems securely which acts as a reverse invoke proxy but there are customers who are yet not convinced with it and want to rely on their on-premise middleware as entry-point into their SAP HR on-premise system.
In such case, customer installs the SCC in their DMZ and also use SAP PI as entry point to their SAP system.
Note: In this case SAP PI doesn't alter the message contents, instead it just passes the message as it is. One important point to note here is that SAP PI changes the message id so you need to find the old and new message ID in your SAP PI system to monitor the messages.
The landscape which is required to support this is shown below.
SAP has given a provision to support this architecture where SAP PI/PO is a passthrough.
Please refer the replication guide from sap.help.com to understand the technical aspects like Transaction codes, programs, web services etc in SAP on-premise which are involved to support the replication.
Sequence of steps is given below.
- Standard program given by SAP requests for data
- SAP PI sends this request to SAP CPI
- SAP CPI requests data from SF Employee Central
- SAP CPI sends the response back to SAP PI via SAP cloud connector
- SAP PI sends the response to SAP on premise
- SAP on premise triggers the confirmation message back to SAP PI
- SAP PI shares this with SAP CPI
- SAP CPI sends this message to SF Employee Central
Note: Sap Cloud Connector is used only for inbound messages to SAP on-premise but not outbound messages.
Adding one more middleware in the replication adds more complexity and creates dependency in case one fails the complete replication will also fail.
Most of the customers prefer to install SCC and use SAP CPI as shown below which is much simpler and mostly followed approach.
2 Comments
