RESTFul and CICSPLEX Architecture
1. Scope: The current stage of RESTFul API enablement included two of the most significant transactions:
- The most used core banking application transaction
- One of the most resources (processor and I/O) consuming transaction.
The transaction were migrated to the new architecture in Production environment.
2. Teamwork: The success of the project was fruit of the spirit of collaboration and synergy among all teams involved.
- SWD Middleware
- SWD Core Banking
- Cyber Security Infrastructure
- IBM Support
- ITID Enterprise Services IBM Z
3. A New Tool for API Design: The z/OS Connect EE API Toolkit was set up and used to create the RESTful APIs. It is an Eclipse-based workstation installed into IBM Explorer for z/OS.
4. Synergy with CICSPLEX architecture: The new architecture was integrated with CICSPLEX. z/OS Connect EE technology makes better use of CICSPLEX technology. These achieves:
- High availability
- Scalability
- Work balance
5. Improved Security: Connectivity to the Mainframe web API is run under HTTPS protocol, encrypted with TLSv1.2. z/OS Connect EE servers are authenticated with Public Key Infrastructure (PKI), making use of digital certificates signed by our own CA. Since the z/OS Connect EE servers and the CICS regions run in the same SYSPLEXS.
Client Authentication for Production, UAT and SAT environments
In these environments the client is authenticated through digital certificates and PKI. The certificates are signed by our own CA again. This reduces human manipulation of secrets and avoids password hardcoding in application code.
During a request to the API the client application presents its digital certificate which is validated by z/OS Connect EE. If validation is successful Security Server RACF maps the certificate to a RACF defined user id. Then, inside Mainframe environment, authorizations are conducted as usual, benefitting from RACF proven security and audit management features.
Client Authentication for Development environment: In Development exists two different kind of APIs, making use of different port numbers:
- API for integration tests: client authentication is done in the same way as described above for the other environments, with PKI.
- API for unit tests: for simplicity’s sake client authentication is set up in basic mode, through user id and password. This authentication schema is usually conducted through the z/OS Connect EE API Toolkit.
Conclusion
The transactional architecture simplification project is due to a major CPU build in the main CICS region. This was because our main transactions were not compatible with the CICSPlex Architecture and used the MQ as a connector, plus other connectivity components, which make, look like transactional Synchronism. With the simplification of Architecture using as a connector from customers or Middleware to z/OS Connect, we transform the transactions into APis, eliminate fault points and achieve a native sync communication.
The observed optimization in CPU consumption and workload distribution is the result of the synergy of the API enablement through z/OS Connect and the adoption of the CICSPlex architecture combined with a better use of WLM features with respect to CPU, CICS and transactions within the CICS prioritization and workload management.
With z/OS Connect the response time were significant decrease (around 40% and 42% less). This is achieved in the “transport layer” of the connection between Middleware servers and the core banking backend, thus reflects the “net time” directly affected by the change in the connectivity architecture.
The other lines show the “total time”, and are important because show the user perception of the change. Additionally we can take advantage of reutilization of the Z asset, and think in Z as an “open platform”.
This important project was critical for the bank because it is a new way to access assets within IBM Z. It would not have been possible without the help of Gustavo Vitaliani and Gabriel Santoro, both leaders of system programmers.