Response "SAP"

If the SAP service of the Integration Server is active, the output data can be sent to connected SAP systems. For this purpose, a function module (RFC) on the SAP system can be called. See also section SAP RFC. For the appropriate target structure see section Loading IDoc structure from SAP repository.

Settings


(1) SAP alias: The SAP alias of the connected system (see configuration file ./etc/sap.xml).

(2) RFC: The name of the function module to be called on the SAP system.

(3) All records in one call: If this option is selected, all records are transferred to the function module, otherwise, an RFC call is made for each record. The nodes in the target structure for fields and structures may only be traversed once per RFC call. In contrast, the nodes for tables may be traversed multiple times. Each iteration corresponds to one line in the table.

(4) Return data: To make this option selectable, the profile must have an Input Agent of type "HTTP" and (3) must be set. If (4) is set and (5) is not set, then the RFC response is returned to the external client (that sent the HTTP request to the profile) as HTTP response (including HTTP headers). If (5) is set, then (6) must also be set to Synchronous for option (4) to be selectable. If (4) is then set, the first converted result of the subsequent profile that was triggered by this Response is returned as the HTTP response. See also section Profile chains. Note: The HTTP response is always encoded in UTF-8.

(5) Forward SAP response as message: The response of the SAP system can be forwarded to another profile via Message. Below you specify the name of the subsequent profile and its Message Context and Message Queue. So the subsequent profile needs to have an Input Agent of type Message.

(6) Message type: There are three different types of messages.

  • Synchronous. The profile sends the message and does not continue until the response has been received.

  • Asynchronous. The profile sends the message and continues immediately. The response is irrelevant for the further profile execution.

  • Persistent. Works almost like Asynchronous. Additionally, however, if the remote system cannot be reached, the message will be stored and there will be a resend attempt every 50 ms. If the message could not be delivered after a certain time, it is lost.

(7) On synch. message evaluate response: If this checkbox is set, the response of a called subsequent profile is awaited and evaluated. That is, the Response only gets the status success if the RFC call and the subsequent profile were successful. If the checkbox is not set, only the RFC call need to be successful.

(8) In format: The format in which the data is passed on to the subsequent profile. The format must correspond to the document type of the subsequent profile. Available formats are CSV , Fix record , XML and SAPXML . Note: The advantage of using the SAPXML format is that if the RFC/BAPI provides 'deep data types' in the response, these can be parsed and processed. These are String/XSTRING, tables in the EXPORT parameters, tables in tables, and the CHANGING parameters. Disadvantage: The source structure of the subsequent profile can only be created out of the RFC response received after executing an RFC call.

(9) Mark whole job as failed if this response fails: Normally a job is not necessarily considered to be erroneous if a single Response fails (see section Status of Response - Error Behaviour). But it can be enforced with this option here.

(10) Additional text on error: Here you can specify an additional log text for the error case.