IBM App Connect Enterprise, Version 11.0.0.2 Operating Systems: Windows, Linux


CICS Transaction Server for z/OS two-tier connectivity

The CICSRequest node support in IBM® App Connect Enterprise provides direct communication with CICS® Transaction Server for z/OS® (two-tier connection) by sending Distributed Program Link (DPL) requests over TCP/IP-based IP InterCommunications (IPIC) protocol.

The CICSRequest node also supports communication with CICS through CICS Transaction Gateway (three-tier connection). For more information about three-tier connections, see CICS Transaction Server for z/OS three-tier connectivity.

A direct two-tier connection from IBM App Connect Enterprise to CICS can be made by using the CICS Connection policy or by setting the properties directly on the CICSRequest node.

CICS Connection policy connections:

A CICS connection from IBM App Connect Enterprise is made to a listening TCPIPSERVICE resource in CICS. When that connection is established, the active connection between IBM App Connect Enterprise and CICS is represented by an IPCONN resource.

Each CICS Connection policy results in a separate connection to CICS, so for every policy that is being used, there is an IPCONN resource in CICS. The properties of the IPCONN resource determine the properties of the link between IBM App Connect Enterprise and CICS.

The IPCONN resource that represents an IBM App Connect Enterprise to CICS connection can be created in two different ways; autoinstall or pre-defined.

Autoinstall:
Autoinstalling a connection means that when IBM App Connect Enterprise connects, the resource is created, and when IBM App Connect Enterprise disconnects, the resource is discarded. In this setup, the IPCONN is created from a template IPCONN that is named by a user-replaceable-module (URM), which is named in the TCPIPSERVICE resource. Properties of the IPCONN are based on that template resource.
Pre-defined:
Alternatively, the IPCONN can be pre-defined by using standard CICS resource definition mechanisms, such as CICS Explorer, CEDA, or CICSPlex® Systems Manager (CICSPLEX SM). If the IPCONN definition is created in advance, it is matched to the incoming connection by using the IPCONN APPLID and Network ID properties, which correlate to the CICS APPLID and CICS APPLID qualifier properties that can be set on a CICS Connection policy.
The advantage of pre-specifying the IPCONN is that you can tightly control the properties of incoming connections, including the security properties and the number of simultaneous requests. However the following rules apply:
  • Do not configure different integration servers to use the same CICS Connection CICS APPLID and CICS APPLID qualifier combination to connect to the same CICS region. An IPCONN is tied to IBM App Connect Enterprise through the CICS Connection policy properties CICS APPLID and CICS APPLID qualifier. If this is attempted, only the first policy successfully connects.
  • Do not specify a host name and port when defining the IPCONN resource in CICS. These fields are used for connections between CICS regions only, they must not be set for IBM App Connect Enterprise connections.

The following diagram shows how IBM App Connect Enterprise can directly connect to CICS by using a CICS Connection policy.

The diagram shows how IBM App Connect Enterprise can connect to CICS Transaction Server for z/OS by using a CICS Connection policy.

The two-tier direct CICS connection model is based on the following rules:
  • Each policy name results in a separate connection to CICS.
  • The CICS Connection policy must only be used from one integration server, because any further integration servers attempting to use the same policy thereafter fail to connect.
  • The CICS APPLID and CICS APPLID qualifier properties in the policy are used to find the IPCONN resource in CICS. A chosen CICS APPLID and CICS APPLID qualifier combination must be unique to the CICS region. Only one IPCONN resource can exist with that combination.
  • More than one message flow instance can use the CICS connection, however each request that goes through a CICSRequest node uses a conversation on the connection for the duration of the request.

When defining an IPCONN resource in CICS, consider the following properties:

  • CICS APPLID and Network ID

    The CICS APPLID and Network ID properties must match the CICS Connection policy clientApplid and clientQualifier properties.

  • CICS host name and Port number

    The CICS host name and port properties must be used for connections between CICS regions only, they must not be set for IBM App Connect Enterprise connections.

  • CICS TCPIPSERVICE

    IPCONNs are owned by a parent TCPIPSERVICE resource in CICS.

  • CICS Receivecount

    The CICS Receivecount property controls the number of simultaneous requests that can be performed over the connection. The number of simultaneous requests defaults to 100 for autoinstalled connections.

  • CICS Sendcount

    The Sendcount property must be set to 0 because the Sendcount property is used for CICS connections only, and must not be used for IBM App Connect Enterprise connections.

  • CICS LINKAUTH

    The CICS LINKAUTH property controls how the link security is managed. To use a resource in CICS, two security checks are performed; the "flowed" user, which checks the security credentials that are sent from IBM App Connect Enterprise, and the "link" user, which must also have permission for the resource. Both user IDs must have permission to use the resource before the request is granted. The link user ID is given low privileges, which means that even if the flowed user has many permissions, the link user ID can be used to cap the privilege of the connection. If LINKAUTH is set to SECUSER, the SECURITYNAME field is used to specify the link user ID. If set to CERTUSER, the link user is determined from an SSL client certificate that is mapped by RACF®. If USERAUTH(IDENTIFY) or USERAUTH(VERIFY) is specified, the link user ID is not used. Only the user ID received from the TOR is used to determine security.

  • CICS USERAUTH

    The CICS USERAUTH property determines how the flowed user security is configured. If USERAUTH is set to "LOCAL" or "DEFAULTUSER", no user ID or password is to be sent to CICS on a request. This means that all requests use the CICS region ID. If USERAUTH is set to "IDENTIFY", user IDs are flowed without a password. If USERAUTH is set to "VERIFY", user IDs and passwords are required. If USERAUTH(IDENTIFY) or USERAUTH(VERIFY) is specified, the link user ID is not used. Only the user ID received from the TOR is used to determine security.

Each CICSRequest node in a message flow acts as a request on one of the connections to CICS. Which connection is used is determined by the policy that is used.

For more information about configuring the CICSRequest node to get connection details from a CICS Connection policy, see Changing connection information for the CICSRequest node.

You can configure the CICSRequest node or a CICS Connection policy to use SSL protocol. For more information, see Securing the connection to CICS Transaction Server for z/OS by using SSL.

CICSRequest node connections:

If a CICS Connection policy is not specified on the CICSRequest node, and a host name is used directly in the CICS server property, the request shares a connection with other resources that have specified the same CICS server URL. The first CICSRequest node to be used opens the connection to CICS, regardless of whether a URL or a policy is specified in the CICS server property.


bc16140_.htm | Last updated 2018-11-02 14:46:10