Accessing Configuration Data in the Sender Direction 

Use

The procedure for accessing configuration data in the sender direction (from the connected system in the direction of the Integration Server or the PCK) is different to the receiver direction because the ID of the communication channel is not known in the sender direction.

Features

The first processing step of your adapter is to use the LookupManager to read all sender communication channels. You can implement this step as part of the ManagedConnectionFactory.

Open SPIManagedConnectionFactory.java and search for the character string CS_CHINLU.

The example shows that all sender and receiver communication channels are read and saved internally. Use the callback mechanism as described in CPA Event Registration to keep the data up to date.

The example also contains the attribute adapterStatus. Your adapter must contain this global attribute in the adapter metadata. The possible values for this attribute are active and inactive.

The ManagedConnectionFactory first reads all sender communication channels, then generates one or more J2EE application threads for inbound processing, and establishes the physical connection for each channel.

Depending on the external protocol, the following options are available for processing the inbound message:

●     Static

A fixed party/service combination sends these messages through the communication channel. In this case, the adapter can get the address information from the collaboration agreement.

Open SPIManagedConnectionFactory.java and search for the character string CS_AMCPA.

●     Dynamic

Different parties and services send messages to the Integration Server through this channel. In this case, all data for the communication channels must be searched again to ensure that the message is put in the correct communication channel.

Open SPIManagedConnectionFactory.java and search for the character string CS_AMMSG.

Inbound processing can continue in the modules. You configure the security settings in the same way as you do in the receiver direction.

Access Control Using Assigned Users

For sender services of type Business Service or Business System, you can now restrict access to the runtime environment to particular users.

An authorization check is then carried out at runtime prior to inbound processing of the message. This ensures that messages that have the particular service entered as the sender in the message header can only be executed on the Integration Server or in the Adapter Engine by the specified users.

You can restrict this access control further in the sender agreement for the adapter. You can also specify assigned users in the sender agreement.

When the authorization check is performed, the check is first made on the service level and then on the sender agreement level. You perform the check as follows:

●     First check at service level:

○     If ACL (service) is not empty

○     If the user is not in the list of the assigned users for the service

Then send the message back.

●     Second check at sender agreement level:

○     If ACL (agreement) is not empty

○     If the user is not in the list of the assigned users for the sender agreement

Then send the message back.

This authorization check can be used by adapters that have a user/password policy (basic authentication). You can check whether the authenticated user has the authorization to send for the specified service.

The following new API methods are available:

●     lookupManager.getServiceUserByPartyService(..)

●     lookupManager.getServiceUserByService(..)

●     lookupManager.userHasPermission(String user, Binding binding)

For more details about the methods, refer to the JavaDoc.

See also: Service under Access Control Using Assigned Users.