Skip to main content
Version: 5.6

SAP in Redundancy Mode

This section supplements the general redundancy documentation with SAP-specific notes. The reason for this is that SAP triggers, in particular, must be treated differently in redundancy mode than functions that are purely read-only or executed solely locally.

Why SAP Requires Special Attention in Redundancy Mode​

In redundancy mode, the relevant plug-ins are also initialized on the secondary system. This can be problematic for SAP triggers if both systems use identical user data or if SAP does not explicitly specify which OPC router instance should be addressed.

The risks typically lie in the following areas:

  • Parallel initialization of the same SAP-related components on the primary and secondary systems
  • Unclear responsibility during failover if SAP does not specifically address the active system
  • Side effects that are difficult to trace when triggered by SAP actions

What Is Generally Possible​

OPC Router redundancy remains generally usable even in SAP scenarios. However, configurations in which SAP actively triggers events against the OPC Router—and where there is no clear separation between the primary and secondary systems—are particularly critical.

Therefore, do not treat redundancy solely as an infrastructure issue; always verify the specific behavior of the planned SAP triggers in the event of a failover.

1. First, thoroughly test primary operation​

First, configure the SAP plug-in, triggers, and relevant SAP-side objects so that the primary service functions stably on its own. In particular, verify the following:

  • Connection establishment and authentication
  • Correct triggering of the planned triggers
  • Behavior during republishing and restart

2. Carefully Review the User and Authorization Concept​

Do not use identical user data for both OPC Router instances without verification. If parallel initialization or concurrent access can lead to conflicts, the user and authorization concept should be adjusted accordingly.

What matters here is not only whether the login works technically, but also whether SAP can clearly identify and control which system is performing which action.

For SAP triggers, it is particularly important that the involved instances do not run under the same program ID. If the primary and secondary systems use a shared program ID, SAP cannot reliably distinguish which OPC router instance should be addressed. Therefore, use a separate program ID per instance for RFC and IDoc triggers so that SAP can specifically address the active service.

3. Test Failover Specifically in a Test Environment​

Explicitly test the switch from the primary to the secondary service and the switch back using the actual SAP triggers in use. In particular, check the following:

  • whether SAP reaches the correct system after the failover
  • whether triggers continue to fire as expected
  • whether duplicate or conflicting effects occur
  • whether the program ID configured on the SAP side continues to point to the desired active instance after the failover

4. Evaluate Trigger Types Individually​

Do not treat RFC- and IDoc-based triggers as identical across the board. Depending on the SAP-side configuration, target addressing, and technical user, the effects in redundancy mode may vary.

Therefore, use the respective trigger documentation as a technical basis and always supplement it with a project-specific failover test.

Practical Recommendations​

  • For production scenarios, use only configurations that have been tested in primary operation and in the event of a failover.
  • Document on the SAP side which destinations, users, and trigger functions belong to the active OPC Router instance.
  • Use and document a separate program ID for RFC and IDoc triggers for each OPC Router instance.
  • Plan changes to SAP triggers so that their behavior can be verifiably checked after release and service switchover.