Adapter for SAP 10.1 | webMethods Adapter for SAP Documentation | webMethods Adapter for SAP Installation and User’s Guide Documentation | Package Management | Using the Adapter in a Clustered Environment | Clustering Considerations and Requirements | Considerations about Adapter for SAP Centralized Transaction Store or Shared Transaction Store
 
Considerations about Adapter for SAP Centralized Transaction Store or Shared Transaction Store
When using multiple instances of Adapter for SAP for inbound RFC load balancing, you configure RFC listeners with the same Program ID on each Adapter for SAP so that the SAP Gateway can perform load balancing and route tRFC documents to different adapters for SAP. The SAP Gateway also sends out tRFC transaction status information updates to Adapter for SAP listeners. By default, this transaction status information is persisted locally in the adapter's transaction store.
However, communication failures, for example when a network connection fails or an Integration Server becomes unavailable, can lead to situations where the SAP Gateway is sending the tRFC transaction status information not to the single Adapter for SAP that has processed the tRFC, but also to other, different adapters for SAP in the group. In this case, the transaction status information persisted in the local transaction stores of the various adapters can end up in an inconsistent and invalid state.
To prevent these synchronization issues with tRFC transaction information updates, you can configure your group of adapters for SAP to use a single Shared Transaction Store (STS) or Centralized Transaction Store (CTS) that hosts all transaction state information for all adapters for SAP in the group.
The CTS implements a client/server solution, where one Adapter for SAP hosts the centralized store (the CTS Server) and all other adapters for SAP access this store as clients (CTS clients). The Shared Transaction Store implements a direct shared store. Since all the transaction status information updates are now routed to a single transaction store, no more duplicate, incomplete, or inconsistent transaction state information will be persisted in the local transaction stores.
You do not have to set up an STS or CTS as an Integration Server cluster. Instead, you can use the STS either with an Integration Server cluster or with a group of adapters for SAP on independent Integration Servers.
An STS (or CTS) is needed when you want to implement robust inbound or outbound load balancing using tRFCs and IDocs. If you just run a single Adapter for SAP, then an STS (or CTS) will not make any sense . If you run a group of completely independent adapters for SAP and do not intend to use load balancing or tRFCs or IDocs with these adapters, then configuring a CTS will not be useful.
Adapters for SAP configured as CTS Clients will persist and look up all the transaction information in the CTS, therefore the availability and performance of the CTS Server is of importance. Ensure that the Adapter for SAP that hosts the CTS (the CTS Server) is always started before all other adapters for SAP (clients). Also, ensure that the CTS server is not shut down or disabled while other CTS clients are still running and processing transactions.
The STS server will be a single point of failure. WmSAP 10.1 therefore introduces the more robust and more performant STS as a substitute for CTS. The CTS configuration is deprecated and should be changed to an STS configuration.
For more information about configuring the Shared and Centralized Transaction Store, see Shared Transaction Store and .