Transaction Handling

Managing Transactions and the Transaction Store

Adapter for SAP comes with a transaction manager that allows you to monitor the transaction state for all messages associated with a transaction ID that uniquely identifies the transaction. The transaction ID can be up to 24 alpha numeric characters in length. If Adapter for SAP receives a message without a transaction ID, it can create one for the message.

The message itself is stored in the transaction store. The transaction store can be a directory in the file system or in a MySQL database. By default, the transaction store is located in the file system on Integration Server on which an individual Adapter for SAP is installed. Alternatively, it can be centrally located in an external directory in the file system or in a MySQL database shared by a group of Adapter for SAP (Shared Transaction Store) or on an Integration Server on which one Adapter for SAP is designated as the server, and is available to a group of adapters for SAP (Central Transaction Store) . For complete information about configuring and working with the Shared Transaction Store, see Shared Transaction Store.

For complete information about configuring the transaction store in MySQL, see Installing Adapter for SAP.
Note:
  • Transactions are stored in a directory in the file system for local transactions by default.
  • Transactions are stored in a directory in the file system if multiple Adapter for SAP instances are configured for CTS or STS.
  • Transactions can be stored in a MySQL database for a single or multiple Adapter for SAP instances.

Use the Transactions screens to view and manage the transactions that Adapter for SAP records in its transaction store. Here you can view transactions and their processing log as well as delete transactions that are no longer needed.

Note: Adapter for SAP does not support XAResource transaction (XA_TRANSACTION).

Viewing Transactions

About this task

You view transactions for a local Transaction Store, or a Centralized Transaction Store (CTS) or a Shared Transaction Store (STS) in the same way. In a local Transaction Store, you can view only the transactions executed by that individual adapter; in a CTS or STS, you can view the status of all the transactions executed by any adapter in the group.

To view the transactions in the transaction store

Procedure

  1. In the Adapters menu in the Integration Server Administrator's navigation area, click Adapter for SAP.
  2. In Adapter for SAP menu, click Transactions. The Transactions screen displays all transactions.
  3. By default, Adapter for SAP displays transactions in pages of 20, in order to avoid a timeout or out-of-memory of the web browser in case there is a large number of transactions in the store. To display more or fewer than 20 transactions per page, specify a value in the Page Entries field.
  4. To filter the displayed list of transactions:
    1. Enter filter criteria in any of the following fields in the Transaction List Filter section of the Transactions screen: Sender, Receiver, Message Type, TID, State, Begin Date, and End Date.

      The Begin Date and End Date fields can be used to restrict the displayed transactions to a specific time interval. The date format entered into these fields must match the date format displayed in the Date field in the Transaction List.

      When you enter a filter term in one of the fields, only those transactions that match the term will be displayed. Regular expressions are supported to allow flexible filter criteria matching. For a detailed description of regular expressions, see IBM webMethods Service Development Help for your release.

    2. Click Apply Filter. The transactions that match the filter criteria are displayed.
      Note: Clicking Apply Filter runs your filter criteria against all transactions. If you want to refine your search, specify additional or more restrictive filter criteria, and then click Apply Filter.
    3. To re-display all transactions, clear all filter fields and click Apply Filter.
  5. To view detailed information for a transaction:
    1. For the transaction you want to view, click its corresponding transaction ID in the TID column.
    2. The TID screen displays the transaction ID, sender, receiver, message type, date when this transaction was first received by Adapter for SAP and time when the current state was set, current state, the last error (if any), and an audit log that shows state changes, error messages and the various steps that have processed the message.
      The State field corresponds to the different states of the tRFC protocol. If the message was not received via tRFC but via a different protocol (like HTTP), the transaction store tries to imitate the tRFC status handling, but the meaning of the single states is slightly different in this case. The following describes the valid states of a tRFC transaction:
      Status Meaning (tRFC) Meaning (other protocols)
      Created The sender has sent a transaction ID, which was accepted by Adapter for SAP transaction manager. (No data sent yet.) The sender has sent a transaction ID and data, which was forwarded to the transaction store.
      Rolledback Execution of the transaction has failed. The sender may retry the transaction again at a later time.

      The Administrator should manually follow up transactions in status Rolled back as follows:

      Try to find and eliminate the reason of failure and then:

      • Re-send the transaction from SM58, if it originally came from an SAP system
      • Ask your partner to re-send the transaction, if it originally came in via FTP or HTTP.
      • If the transaction was initiated by a local service, re-invoke the service.
      		Execution of the transaction has failed. The sender may retry the transaction again at a later time.
      Committed The sender has acknowledged that the transaction executed successfully. Execution of the transaction on Adapter for SAP finished with a success message.
      Confirmed The sender has promised never to send this transaction again. So the TID may be deleted, as there is no need anymore to protect against duplicate processing of the same transaction. This is used only if the external client invokes the service pub.sap.transport.*:InboundProcess again, with $action set 4, after the transaction has been executed successfully. In this case and if the transport supports it, the Confirm event has been forwarded to the final receiver, so that it is able to clean up its ARFCRSTATE table and remove the TID from it.
    3. If the storing of message bodies has not been disabled on the Routing or RFC listener, it is also possible to view the transaction's complete pipeline or its message body as either XML or HTML (IDoc only) from the View Transaction screen.
    4. To delete this transaction, click Delete.
    5. To return to the list of transactions, click Return to Transaction List.

Deleting Transactions

About this task

You delete transactions from a local Transaction Store and a Centralized Transaction Store (CTS) or a Shared Transaction Store (STS) in the same way. If a transaction store contains transactions that are no longer needed, you can delete them. In a local Transaction Store, you can delete only the transactions executed by that individual adapter; in a CTS or STS, you can delete any transaction executed by any adapter in the group.

Important: If you delete a transaction in a CTS or STS, the transaction will not be available for all the adapters in the group. Make sure you delete only the transactions that are not needed by any adapters in the group.

To delete transactions from the transaction store

Procedure

  1. In the Adapters menu in the Integration Server Administrator's navigation area, click Adapter for SAP.
  2. In Adapter for SAP menu, click Transactions.
  3. Use any of the following ways to delete transactions:
    • To delete transactions one at a time, click Delete in Deletecolumn corresponding to the transaction that you want to delete.
    • To delete only the transactions that match your filter criteria, all at the same time, click Delete Filtered Transactions.
    • To delete all transactions in the transaction store at once, click Delete All Transactions.

Automatic Cleanup of the Transaction Stores

About this task

As the size of the transaction store increases, you should consider creating a flow service that periodically purges the store of transactions that are no longer needed.

  • To clean up a local Transaction Store, configure the flow service on each adapter.
  • To clean up a Centralized Transaction Store or a Shared Transaction Store, configure the flow service on only one of the adapters for SAP in the adapter group. For best performance this should be Adapter for SAP that is the CTS server.

To purge certain transactions from the transaction store periodically

Procedure

  1. In Designer, create a flow service that invokes the pub.sap.transaction:sweep service.
  2. Pass the following parameters to the sweep service using the Set Value modifier in the pipeline.
    For this parameter… Specify…
    state The transaction state.
    elapsedTime The number of minutes that the transaction has been in status state.
    maxTrxCount The maximum number of transactions to delete each time that pub.sap.transaction:sweep runs.

    For information about the sweep service, see pub.sap.transaction:sweep.

  3. In the IS Administrator UI go to Server > Scheduler and schedule this flow service to run periodically.

Example

To periodically purge all transactions that have been in the Confirmed state for longer than 30 minutes, you can create a service called app:purgeConfirmedTRX with those state and time parameters. You also specify how many transactions every invocation of the service will purge. This is so you can control the pace of your maintenance jobs without putting to much load on Integration Server at one single time. It is also a good idea to schedule the job at times when there is not much load on Integration Server.

Configuration Parameters for the Transaction Manager

The transaction store reacts to the following configuration parameters, which can be set in the file <install_dir>\config\server.cnf or per routing/RFC listener or on the notification level for a local Transaction Store and for a Centralized Transaction Store Server only. Some of these settings influence the performance of the transaction store.

Note: The transaction store performance will influence the general performance of Integration Server depending on the transactional throughput, that is, size of the docs and docs per second.
  • On each RFC Listener and on the routing listener you can set field "Store message body" to "On" or "Off".

    If this parameter is set to "Off", Adapter for SAP does not save the message body of incoming transactions.

  • On each RFC Listener and on the routing listener you can set field "Log transaction status" to "On" or "Off".

    If this parameter is set to "Off", Adapter for SAP does not maintain any transaction and status information in the transaction store.

  • On each ALE Notification and for the Routing Notification you can set field "Monitor IDocs" to "On" or "Off".

    If this parameter is set to "On", Adapter for SAP links the IDoc packet's TID with the DOCNUMs of the IDocs in that packet, so that later ALE IDoc Monitoring is possible. See Using the ALE Monitoring Features Via Adapter for SAP for more information.

  • watt.sap.xtn.cacheFlushPeriod

    For more information, see watt.sap.xtn.cacheFlushPeriod.

  • watt.sap.xtn.cacheTimeToLive

    For more information, see watt.sap.xtn.cacheTimeToLive.

  • watt.sap.xtn.fastAsyncMode

    For more information, see watt.sap.xtn.fastAsyncMode.

Using the ALE Monitoring Features Via Adapter for SAP

You can monitor the ALE transactions for a local Transaction Store and for a Centralized Transaction Store (CTS) in the same way, as described below. The behavior of monitoring will not change because the transactions are executed by individual adapters even in a CTS setup. Only the transaction results are stored in a CTS server.

When an IDoc is sent from an SAP system to Adapter for SAP, the status of the IDoc (as displayed in WE02) will always be "03, Data passed to port OK" (passed to the tRFC queue of the SAP system). However, this status does not provide any information regarding whether the IDoc could be processed successfully by Adapter for SAP and who the final recipient was. To get this kind of information, Adapter for SAP offers three options: IDoc Trace, ALEAUD IDoc and SYSTAT IDoc.

The IDoc Trace feature should be used if you sporadically want to look up the status of certain IDocs. The lookup is done manually and only for a specific selection of IDocs. If you want automatic status update, you should use one of the other two options described below.

Status update via ALEAUD IDoc can be used if the final recipient is again another SAP system. The most common case will be the connection of two SAP systems via the Internet like this:

SAP system (sender) -> Integration Server 1 ->Internet (http) -> Integration Server 2 -> SAP system (receiver).

In all other cases, status update via SYSTAT IDoc must be used. Integration Server acts here like an EDI Subsystem and returns status information and information about the final receiver (receiving e-mail address, Web Server URL, FTP Server, third party system, etc.) to the sender.

IDoc Trace

Overview

The ALE Monitor allows you to make inquiries about the processing status of an IDoc in the receiving system actively from within the sending system. In SAP systems of release < 4.6C this can be done with the transaction BDM2 (Cross System IDoc Reporting) and from release 4.6C on with transaction BD87 (Status Monitor for ALE Messages). As inputs you can specify certain selection criteria, like Document Number, Message Type, LS of receiver and date ranges. The system then makes a synchronous RFC call (IDOC_DATE_TIME_GET) to the LS that received the IDocs, with a list of DOCNUMs corresponding to the selected IDocs. (From transaction BD87 you have to hit the toolbar button "Trace IDocs" after the selection of the IDocs.) This function call returns for each IDoc the DOCNUM, under which it was saved in the receiving system, the receiving time and the current processing status in the receiving system.

Prerequisites

  • The IDoc Trace functionality only works for IDocs exchanged between partners of Partner Type LS (Logical System).
  • In order to be able to make this synchronous RFC, the partner profile of the LS, which represents Integration Server, must contain an outbound parameter with message type SYNCH.
  • Also the Function Call to an LS of type "tRFC Port", like Integration Server, is only executed if the SAP system is of release 4.6D or higher. For older releases you have to apply the following hot packages:
    R/3 Release Hot Package
    3.1I SAPKH31I67
    4.0B SAPKH40B56
    4.5B SAPKH45B35
    4.6B SAPKB46B22 and SAPKH46B22
    4.6C SAPKB46C11 and SAPKH46C11

Prepare Adapter for SAP for IDoc Trace

To set up Adapter for SAP for IDoc tracing proceed along the following steps:

  1. For your routing notification or ALE adapter notification you want to monitor IDocs, set the value for field "Monitor IDocs" to "On" using Designer.
  2. For each SAP system from which you want to receive and trace IDocs, create an RFC adapter notification for IDOC_DATE_TIME_GET and assign service pub.sap.monitor.idoc:trace.
Note: Depending on how Adapter for SAP processes the IDoc it receives, different information will be returned. By default, the creation date and time at the receiving system and the status will be returned. If the IDoc will not be forwarded to another SAP system, Adapter for SAP is the receiving system.

However, if the IDoc is forwarded to an SAP system (either by invoking a routing notification with outbound transport set to ALE or by invoking pub.sap.transport.ALE:OutboundProcess or pub.sap.client:sendIDoc directly or from a remote Integration Server) Adapter for SAP invokes IDOC_DATE_TIME_GET directly against the receiving SAP system. This action returns additional information, like the IDoc number, from the receiving SAP system. All remote Integration Servers that receive IDocs via a remote invocation of pub.sap.transport.ALE:InboundProcess should therefore also support IDoc Tracing.

Status Update Via ALEAUD IDoc

Preparation

If the final receiver is an SAP system, the IDoc ALEAUD can be used to report status information from the receiver back to the sender. To setup this scenario, the following settings have to be created in the distribution models of the participating Systems:

(MATMAS is used in this example)

  • Sending SAP System: For the LS that represents the receiver, set up a partner profile, that has MATMAS as an outbound parameter and ALEAUD with process code AUD1 as an inbound parameter.
  • Receiving SAP System: For the LS that represents the sender, set up a partner profile with an outbound parameter ALEAUD and an inbound parameter MATMAS. Also in the distribution model the following model view has to be created:

    Sender: T90CLNT090 (or LS, which received the IDoc, if different)

    Receiver:LS of sender

    Message type: ALEAUD

Here add a Filter with value "MATMAS".

Next you have to schedule a job, which executes a variant of the report RBDSTATE. The variant has to include the LS of the sender as selection parameter. This should send out an ALEAUD IDoc to the Integration Server.

Further Setup in Adapter for SAP

About this task

To set up Adapter for SAP for status update via ALEAUD proceed along the following steps

Procedure
  1. For the routing notification or ALE adapter notification you want to use to monitor IDocs, set the value for the Monitor IDocs field to On using Designer.
  2. After all this has been set up, the ALEAUD IDoc can be routed as usual like a "normal" IDoc. Here -and in all other cases, where sender/receiver information in the IDoc Control Header has been changed by a mapping-only one thing has to be taken into account: the last Integration Server, which pushes the ALEAUD into the original sending system, has to set the values of EDI_DC40-SNDPRN and EDI_DC40-RCVPRN to the inverse of their original values.

    For example: If your original IDoc went out with a header segment such as: 

    SENDER              Receiver
    LS T90CLNT090       LS XYZCLNT123

    Then the ALEAUD has to be pushed in with this header: 

    EDI_DC40-SNDPRN = XYZCLNT123
    EDI_DC40-RCVPRN = T90CLNT090

    This can be achieved by adding the service pub.sap.monitor.aleaud01:swapSenderReceiverLSas preprocessing service to the routing notification service.

Status Update Via SYSTAT IDoc

Overview

In this case Integration Server can be considered as a kind of EDI Subsystem. If the SYSTAT feature is enabled, it automatically sends a customary EDI Subsystem Status and some additional information for each IDoc it received back to the original sender. You can decide for each routing notification or ALE adapter notification whether SYSTAT information should be reported to the sender or not. The following information is then reported in addition to the status:

  • Program that set the status (Adapter for SAP)
  • Routing notification or ALE adapter notification that processed the IDoc
  • The key (TID) under which the IDoc can be found in Adapter for SAP
  • Date and time of status change
  • In case of an error status: explicit error message
  • In case of a success status: explicit information about the final receiver

Adapter for SAP sends the following status:

  • If everything went ok the first time: "06 Translation OK" and "12 Dispatch OK"
  • If an error has occurred the first time: "11 Error during dispatch"
  • If everything went ok at a later retrial: "13 Retransmission OK"
  • If there was still an error at a later retrial: "23 Error during retransmission"
  • If no information on the IDoc could be determined: "04 Error within control information of EDI subsystem"

Set Up the Participating SAP Systems

In each SAP system that is to receive SYSTAT IDocs from Integration Server, you need to configure the following settings:

In SAP systems of Release 3.1H - 3.1I you need to perform the following additional step, before continuing with the general setup:

Go to WE42 (Process codes, inbound) and open the two tree branches Inbound with ALE service > Processing by task and Inbound without ALE service > Processing by task. You need to reassign the process code STA1 from without ALE service to with ALE service, if this has not already been done. To do this, proceed as follows:

  1. Mark the node Inbound without ALE service > Processing by task > STA1 Status record from IDoc with the cursor and then press the Reassign button (F6).
  2. Confirm the popup
  3. Double click on the node Inbound with ALE service _ Processing by task
  4. In the following screen press the Save button (F11).

General setup:

  1. Open SALE (Distribution (ALE)) and select Basis configuration > Set up logical system
  2. > Maintain logical systems to add a new logical system for the Integration Server if you do not have one yet. If you name it BUSCON, the Integration Server will recognize it automatically; otherwise, you will have to make the name known to the Integration Server as described later.
  3. In WE20 (Partner Profiles), create a partner profile with Partn.number =the name you chose in step 1 (BUSCON) and Partn.type = LS. After you saved it, add an Inbound Parameter to it as follows:

    Message type = STATUS

    Process code = STA1

Prepare Integration Server for Automatic SYSTAT IDoc

About this task

In the Integration Server, you have to setup these elements to enable automatic status update via SYSTAT:

Procedure
  1. If you chose a different name from BUSCON for the logical system above, shutdown Integration Server and add the following parameter to ...\IntegrationServer\config\server.cnf: 
    watt.sap.systat01.partnerNumber=<NameOfLogicalSystem>.

    Start the Integration Server again.

    With BUSCON you can omit this step.

  2. To mark a routing notification or ALE adapter notification for automatic status update, edit the notification and set the value for field "Monitor IDocs" to "On".
  3. Go to Server > Scheduler > Create a scheduled task and schedule the service pub.sap.monitor.systat01:report.

    Here you specify time intervals for the Service. You should try to schedule it for times when you know that there is little load on the system. On the other hand, in order to prevent the resulting SYSTAT IDocs from getting too big, you should schedule it often enough, so that at most around 2000 IDocs have been received by Adapter for SAP since the last run of the report service.

    This service collects all the necessary information and error/success messages for those IDocs, which the notifications chosen in step 2 have processed since the last run. For each SAP system that has sent any such IDocs to Adapter for SAP, it creates and submits one SYSTAT IDoc containing all this information.

Shared Transaction Store

As an alternative to storing transaction information locally, Adapter for SAP provides a Shared Transaction Store (STS) configuration that enables you to run several Adapter for SAP in parallel to improve reliability. The STS manages the transaction states for multiple Adapters for SAP, and can be used with either Integration Server cluster or with a group of Adapter for SAP on independent Integration Servers. By providing a central location in which to store transaction information, an STS ensures that the status of incoming tRFCs will remain valid and consistent throughout the adapter group. For more information about using the transaction stores, see Considerations about Adapter for SAP Centralized Transaction Store or Shared Transaction Store

Adapter for SAP group refers to a number of adapters for SAP that belong logically together, that share a single STS and, by sharing the STS, allow reliable tRFC/IDoc load balancing. There can be only one STS per adapter group. All adapters for SAP that are configured to use a specific STS are considered to be in the same group.

To use the STS, configure all the adapters for SAP to use the same external shared directory as transaction store location. For configuration instructions, see Configuring a Shared Transaction Store.

When a transaction is processed by any of the adapter for SAP in the adapter group , the adapter stores the transaction status in the external shared directory, which can be accessed by all the other adapters for SAP in the same group. Note that the way in which the transactions are processed is the same as if they were stored locally, but the status of the processed transactions is stored in the STS Server instead of storing the status locally on each adapter in the group.

Use the Transactions screens to view and manage the transactions that the Adapter for SAP records in the STS. For more information, see:

For additional performance and configuration tasks, see:

Centralized Transaction Store

As an alternative to storing transaction information locally, Adapter for SAP provides a Centralized Transaction Store (CTS) that enables you to run several adapters for SAP in parallel to improve reliability. The CTS manages the transaction states for multiple adapters for SAP, and can be used with either Integration Server cluster or with a group of adapters for SAP on independent Integration Servers. By providing a central location in which to store transaction information, a CTS ensures that the status of incoming tRFCs will remain valid and consistent throughout the cluster or adapter group. For more information about using the transaction stores, see Considerations about Adapter for SAP Centralized Transaction Store or Shared Transaction Store.

Adapter for SAP group refers to a number of adapters for SAP that belong logically together, that share a single CTS and, by sharing the CTS, allow reliable tRFC/IDoc load balancing. There can be only one CTS per adapter group. All adapters for SAP that are configured to share a specific CTS are considered to be in the same group.

To use the Centralized Transaction Store, configure one of the adapters for SAP as the Centralized Transaction Store Server and configure the rest of the adapters for SAP in the group as Centralized Transaction Store Clients. You configure the Remote Server with an alias of "SAPGroupStore" for each Adapter for SAP of your adapter group (and in exactly the same way). For configuration instructions, see Configuring a Centralized Transaction Store (Server).

When a transaction is processed either by the Centralized Transaction Store Server or by any of the Centralized Transaction Store Clients, the adapter stores the transaction status in the server, which can accessed by the adapter server and all the adapter clients. Note that the way in which the transactions are processed is the same as if they were stored locally, but the status of the processed transactions is stored in the Centralized Transaction Store Server instead of storing the status locally on each adapter in the group.

Use the Transactions screens to view and manage the transactions that Adapter for SAP records in the CTS. For more information, see:

For additional performance and configuration tasks, see:

To migrate the CTS configuration into an STS configuration

Note: The Central Transaction Store configuration is deprecated and should be changed into a Shared Transaction Store configuration.
  1. Create a directory with write access in the file system which can be accessed by all the adapters for SAP in the adapter group. For improved reliability, this directory could be located on an external high-reliability NAS.
  2. For all Adapter for SAP in the adapter group, set the configuration switch watt.sap.xtn.cts.txstore to the directory created in the above step.

    The switch can be set in Integration Server Administrator. Click Settings > Extended > Edit Extended Settings.

    In the Extended Settings editor, add watt.sap.xtn.cts.txstore property to specify the shared directory.

    Click Save Changes. The property appears in the Extended Settings list.

  3. Remove the CTS configuration as described in Removing the Configuration of a Centralized Transaction Store for each CTS client in the adapter group. Then shut down all the CTS client adapters.
  4. Remove the CTS configuration as described in Removing the Configuration of a Centralized Transaction Store for the CTS server. Then shut down the CTS server adapter.
  5. Copy the complete contents of packages_directory\WmSAP\txStore directory of the CTS server adapter to the directory created in Step 1.
  6. Restart all the adapters for SAP in the adapter group. The adapters will now use the STS located in the directory created in step 1.

Configuring a Shared Transaction Store

About this task

Use the following instructions to configure a Shared Transaction Store Server.

Note: Perform this procedure for each Adapter for SAP in the adapter group. If one of the adapters is configured to CTS, follow the instructions described in To migrate the CTS configuration into an STS configuration.

To configure the Shared Transaction Store

Procedure

  1. Create a directory with write access in the file system which can be accessed by all the adapters for SAP in the adapter group.
    For improved reliability, this directory can be located on a high-available NAS
  2. Set the configuration switch watt.sap.xtn.cts.txstore to the directory in step 1.
  3. From Integration Server Administrator, click Settings > Extended.
  4. Click Edit Extended Settings.
    In the Extended Settings editor, add or update the watt.sap.xtn.cts.txstore property to the location of the directory created in Step 1.

    For example, to set \\tsclient\D\sharedStore directory as Shared Transaction Store, specify: watt.sap.xtn.cts.txstore=\\tsclient\D\sharedStore

  5. Click Save Changes.
    The property appears in the Extended Settings list.
  6. Restart Integration Server.
    After Integration Server restart, Adapter for SAP will use the specified external directory as STS.

    If the specified directory does not exist or if it is not writable, an error message will be logged during adapter startup and Adapter for SAP will use the default Local Transaction Store instead.

Results

To disable STS configuration and switch back to Local Transaction Store, remove the watt.sap.xtn.cts.txstore property in Extended Settings and restart Integration Server.

Configuring a Centralized Transaction Store (Server)

About this task

Use the following instructions to configure a Centralized Transaction Store Server.

Note: Perform this procedure for Adapter for SAP that is to be the CTS Server.

To configure the Centralized Transaction Store (Server)

Procedure

  1. In the Settings menu in the Integration Server Administrator's navigation area, click Remote Servers.
  2. In the Remote Servers page, click Create Remote Server Alias.
  3. In the Remote Server Alias Properties, specify values for the following fields:
    Field Description
    Alias This is the name by which Adapter for SAP will identify the Centralized Transaction Store configuration.

    You must enter SAPGroupStore in this field.

    Host Name or IP Address This is used to identify Integration Server on which the Centralized Transaction Store is hosted.

    You must enter the host name or IP address of Integration Server hosting the Centralized Transaction Store, or localhost or 127.0.0.1 if it is the local Integration Server.

    Port Number Enter the port number on which Integration Server is running.
    User Name Enter the user name to log on to Integration Server on which the Centralized Transaction Store is hosted.
    Password Enter the password to log on to Integration Server on which the Centralized Transaction Store is hosted.
    Execute ACL Select the required ACL type from the drop-down list.

    Default: Internal

    For more information about assigning and managing ACLs, see IBM webMethods Service Development Help for your release.

    Max Keep Alive Connections Specify the maximum number of repository connections to Adapter for SAP that should be retained. In other words, this is not a maximum number of connections that can be established, but a limit on the number of inactive connections to retain for reuse. If not specified, five keep alive connections are retained.

    Default: 5

    Keep Alive Timeout (minutes) Delay time until an unused repository connection to Adapter for SAP is timed out.

    Default: 1

    Use SSL Select if you want to use the SSL protocol.

    Default: No

    Retry Server This field will not be used by the Centralized Transaction Store.
  4. Click Save Changes.
  5. Reload the WmSAP package.
  6. Restart Integration Server.

Results

To view the configuration and the status of the store, see Viewing Centralized Store Configuration and Status.

Configuring a Centralized Transaction Store (Client)

About this task

Use the following instructions to configure Centralized Transaction Store Clients.

Note: Perform this procedure for each Adapter for SAP that is to be a CTS client.

To configure the Centralized Transaction Store (Client)

Procedure

  1. In the Settings menu in the Integration Server Administrator navigation area, click Remote Servers.
  2. In the Remote Servers page, click Create Remote Server Alias.
  3. In the Remote Server Alias Properties, specify values for the following fields:
    Field Description
    Alias This is the name by which Adapter for SAP will identify the Centralized Transaction Store configuration.

    You must enter SAPGroupStore in this field.

    Host Name or IP Address This is used to identify Integration Server on which the Centralized Transaction Store Server is hosted.

    You must enter the server IP address or the host name of the Centralized Transaction Store.

    Port Number Enter the Centralized Transaction Store Server port number.
    User Name Enter the user name to log on to Integration Server on which the Centralized Transaction Store Server is hosted.
    Password Enter the password to log on to Integration Server on which the Centralized Transaction Store Server is hosted.
    Execute ACL Select the required ACL type from the drop-down list.

    Default: Internal

    For general information about assigning and managing ACLs, see IBM webMethods Service Development Help for your release.

    Max Keep Alive Connections Specify the maximum number of repository connections to Adapter for SAP that should be retained. In other words, this is not a maximum number of connections that can be established, but a limit on the number of inactive connections to retain for reuse. If not specified, five keep alive connections are retained.

    Default: 5

    Keep Alive Timeout (minutes) Delay time until an unused repository connection to Adapter for SAP is timed out.

    Default: 1

    Use SSL Select if you want to use the SSL protocol.

    Default: No

    Retry Server This field will not be used by the Centralized Transaction Store.
  4. Click Save Changes.
  5. Reload the WmSAP package.
  6. Restart Integration Server.

Results

To view the configuration and the status of the store, see Viewing Centralized Store Configuration and Status.

Viewing Centralized Store Configuration and Status

About this task

To view the centralized store configuration and status

Procedure

  1. In the Adapters menu in the navigation area of the Integration Server Administrator, click Adapter for SAP.
  2. In Adapter for SAP menu in the navigation area of Adapter for SAP, click Settings.

Results

At the bottom of the page, you can view the configuration details of Adapter for SAP Group. The Centralized Store field must display Local File System for Centralized Transaction Store Server and Remote File system <server IP Address> for Centralized Transaction Store Clients.

Important: Ensure that Integration Server that hosts the Centralized Transaction Store is always started first, before starting any other Adapter for SAP in Adapter for SAP group. If the Centralized Transaction Store Clients cannot find or access the Centralized Transaction Store Server during adapter startup, they will not be able to start and will shut down with failure. In the same way, it is also important to always shut down all Centralized Transaction Store Clients before shutting down the Centralized Transaction Store Server. The Centralized Transaction Store Clients will otherwise display runtime errors while trying to persist transaction status information, and transactions or transaction changes will be lost.

Removing the Configuration of a Centralized Transaction Store

About this task

If you no longer want a particular Adapter for SAP to use the Centralized Transaction Store (CTS), you can remove or rename the adapter's Remote Server with alias SAPGroupStore by following the instructions in this section.

If you remove the Remote server for Adapter for SAP that is a CTS Client, the CTS Server will display that particular client's status as Inactive in the adapter's Settings page. After reloading the WmSAP package or restarting the Integration Server, Adapter for SAP, the adapter will use its local Transaction Store to persist transaction information.

Important: Is is recommended that you do not remove the CTS Server. However, if you do remove the alias for Adapter for SAP that is the CTS Server, none of the CTS Clients will be able to process any transactions and a message is displayed on the console indicating that the CTS Server is not accessible. When Adapter for SAP that is configured as a CTS client cannot connect to the CTS Server during startup, an error message is displayed, the adapter will only be partially loaded, and transactions are not persisted.

Do not remove or rename the Remote Server Alias for SAPGroupStore while Adapter for SAP is still processing messages. Otherwise the transaction status of these messages could be lost or become invalid.

From Adapter for SAP that you want to remove from the CTS

Procedure

  1. In the Settings menu in the Integration Server Administrator navigation area, click Remote Servers.
  2. On the Remote Servers screen, click Delete for the Remote Server Alias of Adapter for SAP that you no longer want to use the CTS.

    Adapter for SAP removes the Remote Server Alias.

  3. Reload the WmSAP Package.

Results

The affected Adapter for SAP does not register itself with the CTS server during adapter start-up, and will now use its local Transaction Store instead of the CTS to persist all transactions. By doing so, the adapter is effectively no longer part of the logical group of adapters.

Transaction Store on MySQL

Enable the transaction store to use MySQL

Procedure

  1. Follow the steps in Installing Adapter for SAP to install and run the scripts required to use MySQL for transaction store.
    Ensure that the WMTRANSACTION and WMCONFIG tables are created in saptransactionstore database.
  2. Install the latest fix.
  3. Start Integration Server.
  4. Start Designer.
  5. Run pub.sap.transaction:createFunctionalPoolDriverAlias built-in service with the required parameters.
  6. Start Integration Server Administrator.
  7. Click Extended > JDBC pools and perform the following:
    • Ensure that the pool alias is created in the Pool Alias Definitions section. Edit if required.
    • Ensure that the functional alias is created in the Functional Alias Definitions section. Edit if required.
  8. Click Extended > Settings and perform the following:
    Ensure that watt.sap.xtn.useSQL configuration parameter is set to true.
  9. Click webMethods Adapter for SAP > Settings.
    In Misc section > Transaction Store, confirm that MySQL DB is used as transaction store.

Reverting Transaction Store to a File System

Procedure

  1. Start Integration Server Administrator.
  2. Click Extended > Settings and perform the following:
    1. Set watt.sap.xtn.useSQL configuration parameter to false.
  3. Restart Integration Server.

Results

Note: You cannot copy the transactions in the MySQL store back to the file system.