CICS web services an awesome feature integrates User interface (3 of 3)

The following is the sequence how CICS web services works:

• Listen for and receive incoming requests
• Decide what to do with the request (invoke program)
• Allow user written programs to look or message the
  message before it reaches our application program
• Allow user written programs to process SOAP headers
• Deal with WS-Security and WS-Atomic Transaction
  standards
• Parse the user payload, perform conversion, and
  prepare a COMMAREA or container
• Invoke our application business logic program

The next process is as follows:

1. TCPIPService definition tells CICS to listen
2. Systems Programmer defined
3. Tells CICS what port to listen on
4. What host name/address if z/OS is multi-homed
5. If encryption should be used (SSL)
6. Receiving message is performed under the CSOL
   transaction (can be changed by Systems Programmer)

Next process is:

• CICS finds a match on endpoint ‘path’ based on URIMAP
  resource definitions
• Defined by Systems Programmer, and can be dynamically
  defined by CICS
• CICS returns an error if a match on URIMAP is not found
  Work is performed under the CWXN transaction (by default)

The next process is:

1. Pipeline refers to pipeline config file
2. The Pipeline Configuration File specifies a list of optional
   programs (called Handlers) that can look at or massage the
   message before it reaches the target application program
3. DFHPITP uses the WSBind file and WSDL file referenced by the WEBSERVICE definition.

The key internal transactions are:

CSOL ==> CWXN ==> CHIP ==> DFHPITP (prog)