Sender Agreement 

Use

In a sender agreement, you define how the message of a sender is to be transformed so that it can be processed by the Integration Engine (see Inbound Processing).

Prerequisites

When you create a sender agreement, you must specify at least the sender interface and the party or service for the sender and receiver. You can use a wildcard character (*) for the receiver party, receiver service, and the sender interface (note the information provided below under Special Information for Specifically/Generically Defined Sender Agreements).

Defining Receiver-Dependent Sender Agreements

To enter specific values for the receiver, select the checkbox Sender Uses Virtual Receiver (see also Configuring Cross-Company Processes).

Note the restrictions for sender agreements that are assigned a sender communication channel of adapter type File/FTP, JDBC, or JMS (see below).

Features

Parameter Tab Page

Assigning a Communication Channel

To assign a communication channel (sender channel), use the input help (). The input help displays the communication channels that are assigned to the sender.

Principal Propagation

If you want the sender to propagate principals to the Integration Server, select the Propagate Principal checkbox.

This function is only supported for sender channels with adapter type XI, RFC, or SOAP.

More information: Service Users for Message Exchange

More information about the technical configuration of this function: Configuration of Principal Propagation

Security Settings

If you have assigned the sender agreement a communication channel with adapter type XI, SOAP, Mail, or CIDX, you can specify settings for message security.

To be able to configure the security settings, the appropriate checkboxes for message security must be selected in the assigned communication channel: for the adapter types XI and SOAP, select the Web Services Security checkbox; for adapter type RNIF and CIDX, select the checkboxes under Security Settings. In the case of the adapter type Mail, the message protocol must be XIPAYLOAD and the checkbox S/MIME must be selected.

Refer to

●      Security Settings for the Sender XI Adapter

●      Security Settings for the Sender SOAP Adapter

●      Security Settings for Sender Mail Adapter

●      Security Settings for RNIF Adapter

●      Security Settings for CIDX Adapter

When you use the sender XI adapter, the sender SOAP adapter, and the plain HTTP sender adapter, you can specify which HTTP security level is to be assumed for incoming messages. You specify these security settings in the corresponding communication channel (see Configuring the Sender XI Adapter, Configuring the Sender SOAP Adapter, and Configuring the Sender Plain HTTP Adapter). You do not need to make any changes in the sender agreement that references this channel.

Data Scope for Service Metering

For scenarios where communication takes place using the SOAP adapter, statistical information is transferred automatically to the receiver (service provider) using all the senders that call it (service consumers). Data transfer is constantly activated, however during configuration you can specify the data scope that is to be transferred to the provider as part of service metering.

In the sender agreement you define the data scope that is to be provided by the sender and sent using the Integration Server to the receiver.

The sender agreement must be assigned a communication channel with adapter type SOAP for the input fields intended for this are shown.

You can choose between the following values for the data scope:

●      Minimal data transfer

●      Elementary data transfer

●      Extended data transfer

The data transfer scope is set to minimal by default.

In addition to this you can specify the protocol for transferring data.

More information: Service Metering

Assigned Users Tab Page

If you have restricted the access to the runtime to particular service users for a sender service, you can refine these restrictions with respect to the sender interface. Assign the authorized users to the sender agreement that contains the service and the interface in the object key.

To do this, in the Edit Sender Agreement editor, choose the Assigned Users tab page and enter the users.

For more information, see Access Control Using Assigned Users.

Obligatory Sender Agreements

You must specify a collaboration agreement if you want to make security settings for the processing of the message. 

If you do not want to make any security settings, you must nevertheless always specify a receiver agreement for the definition of outbound processing of the message, regardless of the type of adapter that is used.

However, you only need to specify a sender agreement in particular cases (when using specific adapters). This depends which information from the adapter configuration in the sender channel is required for successful inbound processing.

The following table specifies the sender adapter types that always require the definition of a sender agreement (even if no security settings are made).

Obligatory Sender Agreements

Sender Adapter Type	Sender Agreement Required
JMS, JDBC, File/FTP	Required (see remarks below)
RFC	Required
IDoc	-
HTTP	-
XI	-
SOAP	-
RNIF	Required
CIDX	Required
Mail	-
Marketplace	Required
BC	Required

If you use adapters from third-party vendors, check the relevant documentation for the adapters to determine whether you need to define a sender agreement when using their third-party adapters.

Special Conditions when Using the Sender JMS, JDBC, or File/FTP Adapter

In the case of these adapter types, the information about address fields of the message header is determined from the sender agreement that the communication channel is assigned to. The following conditions apply to sender agreements that use communication channels with these adapter types.

●      The sender channel must not be assigned to more than one sender agreement.

●      No key fields may contain the wildcard character (*).

●      At least the interface (name and namespace) and the sender service must be specified in the sender agreement because the corresponding address fields in the message must be set uniquely. The remaining fields are optional (see the key fields for the sender agreement).

The sender agreement is determined from the sender channel at runtime. The information from the sender agreement is used to construct the address header of the message.

Special Information for Specifically/Generically Defined Sender Agreements

Rule: Most Specific Object Has Priority

The rule "most specific object has priority" (see Generic/Specific Definition of Configuration Objects) applies to all adapter types.

The adapter type is not part of the object key of a sender agreement. A sender agreement is therefore always valid for all adapter types. At runtime, the inbound processing of the message is only successful if the message is sent to the adapter that is configured in the communication channel used.

In other words, using the "most specific object has priority" rule, it is implicitly specified (using the communication channel used in the relevant sender agreement) which adapter is to be used for the inbound processing of the message.

Special Case: Multiple Adapter Engines Involved

If multiple Adapter Engines are involved in the message exchange, you must take the following into account.

The "most specific object has priority" rule does not apply to all Adapter Engines in the case of sender agreements. When messages arrive, the Adapter Engine only knows those sender communication channels and the sender agreements based on them that are defined for them.

The following sender agreements are defined in the Integration Directory as examples.

Key Attributes		Sender Agreement1	Sender Agreement2	Sender Agreement3
Sender	Party	A	*	A
	Service	*	*	B
	Interface (Name)	OutboundExample	OutboundExample	OutboundExample
	Namespace	http://example	http://example	http://example
Receiver	Party	P1	P2	P3
	Service	S1	S2	S3
Adapter Engine (x)		AE 1	AE 1	AE 2

(x): Adapter Engine of the communication channel used by the sender agreement

In the configured scenario, the Adapter Engine AE1 receives a message from service B of party A.

Although Sender Agreement3 is the specific sender agreement, the sender agreement that is applied in this case is Sender Agreement1. Sender Agreement3 uses a communication channel that is unknown to Adapter Engine AE1.

In the case of receiver agreements, however, the "most specific object has priority" rule applies to all Adapter Engines.