Recommended
More Related Content
What's hot
What's hot (11)
Viewers also liked
Viewers also liked (17)
Similar to Session 3 _exposing_mainframe_applications_services_v4
Similar to Session 3 _exposing_mainframe_applications_services_v4 (20)
More from nick_garrod
More from nick_garrod (20)
Recently uploaded
Recently uploaded (20)
Session 3 _exposing_mainframe_applications_services_v4
- 1. © 2015 IBM Corporation 1 Exposing mainframe applications and services to mobile
- 2. © 2015 IBM Corporation 2 Where we are in todays agenda 2 • Mobilizing the mainframe • Modernizing mainframe applications for mobile and more • Exposing mainframe applications and services to mobile • Developing an IBM MobileFirst platform application for z Systems • Optimizing applications and data for mobile workloads • Client Use Cases and Getting Started with Mobile and z Systems
- 3. © 2015 IBM Corporation 3 Agenda • The API Economy – Extending the enterprise • IBM API Management • IBM WebSphere Liberty z/OS Connect • Messaging with IBM MQ for z/OS 3
- 4. © 2015 IBM Corporation 44 The API Economy 4
- 5. © 2015 IBM Corporation 5 5
- 6. © 2015 IBM Corporation 6 6
- 7. © 2015 IBM Corporation 77
- 8. © 2015 IBM Corporation 8 Opportunity z Customers have made a significant investment over a long period of time, in developing many valuable assets supporting core business functions (and core competencies) • Leverage these existing assets by exposing as APIs, improving both consumability and governance • Mobile, Cloud based or third-party applications can invoke these APIs for accessing core business functions Reach new customers and markets with new applications and solutions accessing core (z based) business functions, through business partners Improve user experience of existing applications and customers with Mobile applications and new services Improve consumability and governance of enterprise services with API catalog, business control (policy enforcement) and insight (e.g., accountability & chargeback) for the internal and external developers • simplify access to z assets Create new business opportunities by extending “reach” with APIs for accessing enterprise assets
- 9. © 2015 IBM Corporation 9 • Listing and categorizing APIs for easy to find • Describing details on how to invoke an API An example public site listing its published APIs (similar to many others Twitter, Amazon, etc.) Making APIs consumable requires publishing details on their use, making it easy for app developers
- 10. © 2015 IBM Corporation 10 Why API Management? 1. Consumability of the APIs is Key: Easier creation and assembly of API from existing assets/services Visibility of APIs to internal and external developers Easier registration (by consuming applications) and set up including managing entitlement 2. Retaining business control (e.g., enforcing entitlement, accountability/chargeback) and gaining business insight in API invocation Securing APIs using a secure GW from unwanted external invocations (mapping to application level security) and enforcing workload entitlement Business Monitoring of API access in gaining business insight on the use of APIs by external applications, and for accountability/chargeback E n t e r p ri s e S e r v i c e s CICS IMS WAS TPF On-Premise Enterprise APIs Cloud APIs Mobile Applications Cloud-based Services Mobile, Cloud and Third-party Applications invoking z Services using APIs Business challenges addressed by APIM in exposing z based services/assets 10
- 11. © 2015 IBM Corporation 11 Businesses are transforming themselves to participate in the API economy Provide self-service API portals to external/internal app developers Expose business services securely as APIs to developer communities, and analyze API usage Manage & monitor the entire API platform On-premise private Off-premise SaaS Off-premise private Hybrid IBM API Management How do you rapidly and securely expose your business to this developer ecosystem?
- 12. © 2015 IBM Corporation 1212 IBM API Management 12
- 13. © 2015 IBM Corporation 13 IBM API Management: “A Complete API Management Solution” Share with developers 3 Create, assemble and define an API 1 Manage growth & analyze results 4 Secure & scale the API 2 13
- 14. © 2015 IBM Corporation 14 End-to-End Architecture for Mobile, Cloud and Third-party Applications accessing z Assets/Services using APIs 1. Develop Services (Web or REST) On-Premise API Management Cloud APIs Mobile Applications Cloud-based Services Enterprise Transaction Processing E n t e r p ri s e S e r v i c e s CICS IMS WAS TPF Access to systems of records and enterprise data via APIs Jane - Mobile app developer Uses APIs to access Back-End services Bob – developer of z based Services Develops services from CICS, IMS and other z applications 2. Develop Enterprise API s 3. Mobile/Cloud App Enablement Service Enablement • Enables invocation of z applications by remote applications using standard protocols (WSDL, REST) • Converts SOAP or JSON into application specific (e.g., COBOL, PL/I) data and invokes applications API Management • Consumability by internal and external developers (creation and look up) • Entitlement Management (securing, workload enforcement) • Usage monitoring & Analytics Mobile/Cloud/Third-party Application Development • Invokes APIs for accessing SOR Shavon – API developer Develops APIs from z based services Enterprise APIs Security & Integration API Gateway (IBM DataPower Appliance) Create, Publish, Manage & Socialize APIs (IBM API Management) APIM Communication with GW 14
- 15. © 2015 IBM Corporation 15 Discovery and invocation of z Systems based Services z System z/OS Connect JSON WAS Liberty Security & Integration API Gateway IBM DataPower Appliance On Premise API Management CICS API Invocation Create, Publish, Manage & Socialize APIs (IBM API Management) Discovery services Web Services REST Services WOLA based services Web Services IMSSOAP Gateway CICS E n t e r p r i s e S e r v i c e s Discovery of z Services for API Development 1. Get a list of deployed services (Service Identification) - Filter based on technical and business service attributes 2. Get schema for a specific service (API Definition) 3. Get additional deployment details for a service (API Assembly) - e.g., security protocol support, invocation uri Service Development Tool and Enablement Runtimes Web Services CICS and IMS provides separate tools and runtimes; TPF provides runtime libraries REST/JSON CICS and IMS use common z/OS Connect runtime 15 New integrated capabilities in APIM and in z System for easier creation of APIs
- 16. © 2015 IBM Corporation 16 A single, comprehensive solution to design, secure, control, publish, monitor & manage APIs IBM API Management Fully on-premise, multi-tenant solution, for API providers IBM DataPower API Gateway for security, control, integration & optimized access to a full range of Mobile, Web, API, SOA, B2B & Cloud workloads Over a decade of innovation, 10,000+ units sold, 2000+ customer installations worldwide Management ConsoleAPI ManagerDeveloper Portal
- 17. © 2015 IBM Corporation 17 z/OS Connect
- 18. © 2015 IBM Corporation 18 z/OS Connect – What is it? It’s about getting REST and JSON into your mainframe environment in a way that enables you to best take advantage of the assets that exist there: Mobile Ecosystem CICS IMS Batch OtherREST – Representational State Transfer … the use of HTTP URLs that map to a ‘service’, such as ‘query account’ or ‘update data’ JSON – JavaScript Object Notation … a standard of representing data as a set of name/value pairs. This is passed back and forth along with REST request/responses Where z/OS Connect fits • Liberty Profile Server • Function IBM wrote to run in Liberty Profile • No charge function provided with license entitlement to WAS z/OS, CICS or IMS z/OS Connect
- 19. © 2015 IBM Corporation 19 Why z/OS Connect? This represents another component to configure and maintain in your environment. So what value does it bring? • Provides a common and consistent entry point for mobile access to one or many backend systems • Java, so runs on specialty engines • Shields backend systems from requiring awareness of RESTful URIs and JSON data formatting • Provides point for authorization of user to invoke backend service • Provides point for capturing usage information using SMF • Simplifies front-end functions by allowing them to pass RESTful and JSON rather than be aware of or involved in data transformation • Extensible Framework! You could enable Mobile access without z/OS Connect z/OS Connect simplifies and makes the environment more consistent and manageable
- 20. © 2015 IBM Corporation 20 Positioning IBM solutions: accessing z Systems of Record Firewall Firewall DMZ Device DataPower appliance Enterprise Integration CICS Transaction Gateway CICS Mobile Feature Pack DataPower z/OS Connect IMS Mobile Feature Pack IBM Integration Bus (IIB) z/OS Systems of Record Enterprise Integration
- 21. © 2015 IBM Corporation 21 Different Delivery Approaches This is delivered with WAS z/OS, CICS and IMS … objective is to provide different approach paths depending on what you have: WAS z/OS Delivered as function that runs inside Liberty Profile z/OS. Initially will use WOLA (WebSphere Optimized Local Adapters) to access backend. CICS Delivered as part of Liberty Profile that runs inside of CICS region. Will use JCICS interface to access CICS functions IMS Delivered as part of IMS Enterprise Suite (v3.1.1), or downloadable from the Liberty repository, it also has an Eclipse-based tooling platform for service creation and administration (IMS Explorer) These different delivery mechanisms tend to obscure the main story of what it is and how it works, so for now let’s stipulate IBM offers several ways to get this and now focus on some details
- 22. © 2015 IBM Corporation 22 RESTful Services Stands for Representational State Transfer … this is a protocol built on HTTP, using HTTP verbs*, where the URI indicates the service requested: https://mysite.com/CustomerApp/getCustomer?cn=1234 URI = Uniform resource identifier * For example, GET, PUT, POST, DELETE There’s no magic to this … if the URI is understood by the receiving server, then the implied action is taken. What that action is depends on how the server is configured. Knowing what URIs the server supports is important, which is why z/OS Connect has a discovery function that can be used to query for the configured services and details on those services. RESTful services are growing in popularity because it’s easier to implement than other web service protocols such as SOAP, which involves XML and WSDL and parsing …
- 23. © 2015 IBM Corporation 23 JSON – JavaScript Object Notation It is a way of passing data back and forth as a series of name/value pairs. https://mysite.com/CustomerApp/update?cn=1234 URI = Uniform resource identifier { "firstName": "John", "lastName": "Smith", "age": 25, "address": { "streetAddress": “1234 Main Street", "city": “Anytown", "state": "NY", "postalCode": "10021-1234" }, } The data being passed in is appended to the URL and passed in to the server JSON can be passed back to the client as well.
- 24. © 2015 IBM Corporation 24 A Peek Inside z/OS Connect Configuration We’re about to show you the discovery function, which returns a list of configured services. Let’s first look inside z/OS Connect … Liberty Profile z/OS z/OS Connect <feature>zosConnect-1.0</feature> <zosConnectService serviceName="serv1" ... /> <zosConnectService serviceName="serv2" ... /> <zosConnectService serviceName="serv3" ... /> <zosConnectService serviceName="serv4" ... /> server.xml • For z/OS Connect to understand what URIs to handle and how to handle them, you need to configure that information into server.xml More information on server.xml configuration coming up • The sample above is a simplified representation of the configuration for multiple services • z/OS Connect understands its environment based on this configuration data … and it can provide information back using a discovery function
- 25. © 2015 IBM Corporation 25 z/OS Connect Discovery Function A discovery function is provided to allow developers to query for a list of configured services, and drill down for details on a given configured service: https://mysite.com/zosConnect/services Query for configured services https://mysite.com/zosConnect/services/serv1 Query for details on a given configured service JSON object with list of exposed services and their service URLs JSON object with more details on the specific service
- 26. © 2015 IBM Corporation 26 z/OS Connect for Service Invocation Once you have discovered a service that you would like to invoke, you can use z/OS Connect to get the request schema and then invoke the service: https://mysite.com/zosConnect/services/serv1? action=getRequestSchema Get the request schema https://mysite.com/zosConnect/services/serv1 ?action=invoke Invoke the service JSON object that details the request schema for this service JSON object with the response data 26
- 27. © 2015 IBM Corporation 27 z/OS Connect Service Providers A ‘service provider’ is what provides connectivity to a specific backend resource. You may have one or more service providers configured: Liberty Profile z/OS z/OS Connect CICS Program IMS Program To connect to a backend CICS region, for example, you need to specify which CICS region and what mechanism is to be used to connect A ‘service provider’ definition provides that information to z/OS Connect Configured services are tied to service provider definitions to complete the circuit Multiple service providers are supported, as illustrated here Contains code that understand how to work with the backend resource Optimized Adapters JCA Contains code that understand how to work with the backend resource IMS Connect JCA Contains code that understand how to work with the backend resource Configured Service Configured Service
- 28. © 2015 IBM Corporation 28 Data Transformation z/OS Connect accepts JSON data, but then needs to convert that to the data format required by the backend program. Data conversion provides that: Liberty Profile z/OS z/OS Connect JSON Data Structure <zosConnectDataXform id="xformJSON2Byte" bindFileLoc="/u/user1/bindfiles" bindFileSuffix=".bnd" requestSchemaLoc="/u/user1/schema" responseSchemaLoc="/u/user1/schema" requestSchemaSuffix=".json" responseSchemaSuffix=".json"> </zosConnectDataXform> ID of transform section that was referenced in the service definition XML that tells z/OS Connect where the bind file is located and the file suffix that is used XML that tells z/OS Connect where the JSON schema information is located
- 29. © 2015 IBM Corporation 29 Bind Files Bind files are generated with a supplied utility. Bind files provide z/OS Connect with knowledge of how JSON maps to the target data structure //JOB ... //INPUT.SYSUT1 DD * PDSLIB=ZCONNECT.CNTL REQMEM=REQDATA RESPMEM=RESPDATA STRUCTURE=(requestData,responseData) JSON-SCHEMA-REQUEST=/u/user1/schema/GETCUSTC_request.json JSON-SCHEMA-RESPONSE=/u/user1/schema/GETCUSTC_response.json PGMINT=COMMAREA PGMNAME=GETCUSTC WSBIND=/u/user1/bindfiles/GETCUSTC.bnd /* • Bind File • JSON Schema The bind file provides the JSON-to-COPYBOOK mapping; the JSON schema files are used for the getRequestSchema and getResponseSchema methods Request COPYBOOK Response COPYBOOK Bind File Generation Program
- 30. © 2015 IBM Corporation 30 Overview of Interceptors The interceptor framework provides a way to call code to do pre-invoke work and then again to do post-invoke work: Backend Program Request Response Interceptor A Interceptor B Interceptor A Interceptor B In server.xml you can: • Define ‘global interceptors,’ which apply to all configured services • Define interceptors specific to a given configured service • Have services ‘opt out’ of global interceptors z/OS Connect comes with a security interceptor (for authorization) and an audit interceptor (for SMF recording) It is also possible to write your own interceptor and have it called as part of request/response processing
- 31. © 2015 IBM Corporation 31 Optimized Adapters Support in CICS To support WOLA in CICS the following code must be installed. JCL samples provided to do the installation: Task Related User Exit BBO$ BBO# Program CICS Region Liberty Profile z/OS z/OS Connect 1 2 3 4 The WOLA TRUE provides the low-level connectivity for cross-memory communications using Optimized Adapters. 1 The BBO$ long running task handles the calls coming from z/OS Connect. The BBO$/BBO# combination shields the target program from any awareness of Optimized Adapters. 2 The BBO# invocation task is used to perform the EXEC CICS LINK to the target service. 3 Finally, an EXEC CICS LINK is performed and the target service invoked with the data from z/OS Connect passed in. The target CICS program has no knowledge of Optimized Adapters. 4 Adapter JCA
- 32. © 2015 IBM Corporation 32 Optimized Adapters and Batch Programs The Batch Program would use the APIs to “Host a Service” and wait for call from z/OS Connect: Adapter APIs Batch ProgramLiberty Profile z/OS z/OS Connect Business Logic Module Business Logic Static or dynamic call to other modules When the target of the z/OS Connect call is a Batch Program, that program will need to use WOLA APIs to “Host a Service” BBOA1SRV, BBOA1RCA or BBOA1RCS Business logic being called may reside in the hosting batch program, or that program may perform static or dynamic calls to another module where business logic resides Adapter JCA
- 33. © 2015 IBM Corporation 33 z/OS Connect and IMS z/OS Connect interacts with IMS using function provided by IMS and announced in letter ENUS214-220: Liberty Profile z/OS z/OS Connect IMS Service Provider IMS Controller Region IMS Dependent Region Program From a z/OS Connect perspective the concepts are the same as what we’ve shown so far. The syntax for the service provider would be different (IMS Connect vs. Optimized Adapters). And the pointer to the JCA resource adapter would specify the IMS JCA. It is possible to use the Liberty Optimized Adapters with IMS, but only if the program uses the optimized adapter APIs to ‘host a service’ like described for Batch programs IMS Connect ibm.com/common/ssi/cgi-bin/ssialias?infotype=AN&subtype=CA&htmlfid=897/ENUS214-220&appname=USN
- 34. © 2015 IBM Corporation 34 Summary in One Picture A summary of what we covered: Liberty Profile for z/OS z/OS Connect Servlet CICS IMS BatchInterceptors Service Providers Data Transform 1 4 RESTful JSON 3 5 6 7 8 z/OS Connect is software function that runs in Liberty Profile for z/OS. z/OS Connect is described and configured in the Liberty server.xml file z/OS Connect is designed to accept RESTful URIs with JSON data payloads A ‘Service Provider’ is software that provides the connectivity to the backend system server.xml 2 One part of z/OS Connect is a servlet that runs in Liberty Profile z/OS. z/OS Connect provides the ability to transform JSON to the layout required by backend ‘Interceptors’ are callout points where software can be invoked to do things such as SAF authorization and SMF activity recording Initially the backend systems supported will be CICS, IMS and Batch 1 2 3 4 5 6 7 8
- 35. © 2015 IBM Corporation 35 Messaging and z WebSphere MQ
- 36. © 2015 IBM Corporation 36 IBM messaging middleware saves you 2-4 times compared with the cost of rolling-your-own or using FTP Our staggering and somewhat shocking research finding is that custom-built, in- house, hard-coded integration solutions (the majority using free FTP software) are much the most widely-used approach. These often take 2 to 4 times the time and effort to build as Enterprise Integration middleware-supported integration projects, require a similar multiple of ongoing maintenance and support effort, and are insecure, fragile and vulnerable to several serious risks. … IBM application integration costs 2-4 times less than custom-built integration approaches . . . the more applications you integrate the more you save. Software Strategies “Enterprise e-Infrastructure Analysis” 2009 ” “ Number of Application Integration Points Implemented in Enterprise $$$ Effort / Cost Adapted from: Software Strategies Whitepaper, “Enterprise e-Infrastructure Analysis,” 2009 Application Integration Development, Support & Maintenance Size of integration project
- 37. © 2015 IBM Corporation 37 About IBM MQ IBM MQ: Provides versatile messaging integration, from mainframe to mobile, in a single robust messaging backbone. Connects virtually any commercial IT system, with support for more than 80 platforms. Shields application developers from networking complexities, enabling them to develop and deploy new applications faster. Includes administrative features that simplify messaging management and reduce time spent using complex tools. Offers a range of Qualities of Service (QoS). Universal messaging Right QoS Any Deployments Transactional Persistent At-least-once Best-Effort Fire-and-Forget Request-Reply Replay Guaranteed At-Most-Once Client-Server Backbone Point-to-Point Peer-to-Peer Publish/Subscribe Grid Bus Fastest speed Multicast Lowest Latency Unicast Any Skills Languages Orientations COBOL, C/C++, RPC Java, JEE, JMS .NET, C#, VB, WCF AJAX, Perl, Python… Any End-Points Vendor Platforms Applications Operating Systems Devices Web services Web 2.0 JEE, .NET, etc Exploitation & Support SAP, Siebel, etc… Mobile, Wireless, PoS, Sensor, Actuator, RFID… Appliances HTTP, AJAX, REST,… SOAP, WSDL, SOAP/JMS Services Batches Files Messages Resources… Appliance Cloud Mindsets WSDL, XML, WS-* REST, MEST, KISS Open Robust Flexible Scalable
- 38. © 2015 IBM Corporation 38 What does IBM MQ do? Provides messaging services to applications and Web services that need to exchange data and events with: Universally supported by multiple platforms 20 years leading in transactional message delivery • Inherent reliable delivery and transaction control • Native, high-speed handling of any type of message or file • Native lightweight capabilities for supporting remote devices & sensors • End-to-end advanced security • Single point of control, visibility, and management for all data movement • Applications become more flexible and data movement becomes more reliable • Capabilities like the Coupling Facility in z Systems provide unique strengths • Extensive support through years of development, skills and partner ecosystem extensions • Comprehensive single solution reduces complexity of deployment and operation Message Q Manager Q Manager Application Z Application A Channels Pervasive Device Sensor e.g. RFID Regional Office Mobile Phone Petrol Forecourt Refinery Branch Office Retail Store zEnterprise Financial Services & Banking Manufacturing GovernmentRetail
- 39. © 2015 IBM Corporation 39 IBM MQ V8.0 and IBM MQ V8.0 for z/OS Simplify your applications, increased resilience for your business Rapid, reliable, simple, secure exchange of data across applications, systems and services Connect your applications, share information held in files, streamline your processes Scale to meet peaks in transaction workloads and provide the QoS your business demands What’s new in IBM MQ V8.0 Grow your deployment faster, with larger workloads, easier administration Enhanced security with simpler, more powerful operational support New capabilities, additional platform coverage, support for new standards IBM MQ AMS available on IBM i for the first time What’s new in IBM MQ for z/OS v8.0 Exploit z Systems capabilities to improve manageability &performance Improved throughput, scalability and operational tasks Enhanced security and connectivity, with support for new standards No Charge for connecting MQ clients from other platforms to MQ for z/OS Scalable, secure, comprehensive connectivity using reliable messaging everywhere you need it
- 40. © 2015 IBM Corporation 40 Looking at new enterprise workload? • Do you need to: – Support a new business opportunity with a new application? – Build a new application to streamline existing business operations? – Better connect existing applications across your enterprise • Are you: – Looking to deploy on z for mission critical reliability and enterprise class scaling? – Looking to keep operational costs/expense low?
- 41. © 2015 IBM Corporation 41 IBM MQ for z/OS Value Unit Edition • All the power of the premier, unmatched messaging product on z/OS sold under an OTC license. The same product and capabilities as MQ for z/OS – Easy to connect distributed workloads and data directly to applications on z/OS using MQ • Connectivity for your new workload running on your zNALC partition – Connect to your applications running on the same zNALC LPAR, – Connect to another z/OS LPAR using MQ – Connect to MQ on other platforms • Can federate with other instances of MQ for z/OS • Can be managed by the same System Management tool as other instances of MQ for z/OS • The affordable way to connect your zNALC workloads – Has been sold to non-zNALC LPARs where no existing MQ for z/OS (exception needed) • Can be extended with IBM MQ Advanced for z/OS – Adds IBM MQ Managed File Transfer and IBM MQ Advanced Message Security
- 42. © 2015 IBM Corporation 42 Connecting across your enterprise with MQ VUE Standard LPAR with MQ for z/OS zNALC LPAR with MQ for z/OS VUE MQ Server connectivity MQ Server connectivity MQ Server connectivity MQ Client connectivity MQ Client connectivity MQ Client connectivity MQ Server connectivity Aix or Linux Windows Windows z/OS Already have a zNALC LPAR? – Could add new MQ for z/OS VUE to the zNALC LPAR without increasing Operational Expense but gain easy connectivity to the rest of the enterprise. Don’t currently have a zNALC LPAR… – If one is added then adding MQ VUE there will ease connectivity to the rest of the enterprise. In either situation benefits can be seen from not just MQ VUE but if MQ Advanced for z/OS is added it will provide MQ MFT and MQ AMS. If customer doesn’t have MQ for z/OS then MQ VUE is still an option as an exception for LPARs where no MQ on z/OS today SCENARIO Customer has MQ on distributed and MQ for z/OS
- 43. © 2015 IBM Corporation 43 Systems of Engagement meet Systems of Record API Management DataPower Cloud and API Economy CICS TG CICS on Multiplatforms z/Linux IBM MobileFirst Platform WebSphere Application Server z/OS DB2 MQ CICS TS Available as Value Unit Editions z/OS Connect IMS z/OS Tools
- 44. © 2015 IBM Corporation 44 ZSP03978-USEN-00 Thank You
- 45. © 2015 IBM Corporation 45 45
- 46. © 2015 IBM Corporation 46 46
- 47. © 2015 IBM Corporation 47 47
- 48. © 2015 IBM Corporation 48 Overview of server.xml Updates for z/OS Connect z/OS Connect behavior is defined by updates to the server.xml of the Liberty Profile in which z/OS Connect operates: z/OS Connect is defined as a feature in the Feature Manager section, along with WOLA used to get to the backend https://myhost.com/zosConnect/services/HelloWorld <featureManager> <feature>zosConnect-1.0</feature> <feature>zosLocalAdapters-1.0</feature> </featureManager> <zosConnectService id="serv1" serviceName="HelloWorld" serviceRef="wolaHelloService" </zosConnectService> <authData id="cauth1" user="user1" password="{xor}LDo8Ki02KyY="/> <connectionFactory id="wolaCF" jndiName="eis/ola" containerAuthDataRef="cauth1" > <properties.ola/> </connectionFactory> <localAdaptersConnectService id="wolaHelloService" wolaRegisterName="CICSREGA" wolaServiceName="PROGRAM1" connectionFactoryRef=“wolaCF" </localAdaptersConnectService> This defines the service provider – WOLA in this case – that provides the connectivity to the backend CICS region This defines a service – HelloWorld – that will be exposed to Mobile users. It maps to a service provider that defines how the backend CICS will be accessed.
- 49. © 2015 IBM Corporation 49 Multiple Configured Services You provide definitions for each service you wish to expose using z/OS Connect. For example, this shows Update, Create and Delete: https://myhost.com/zosConnect/services/ContactCreate https://myhost.com/zosConnect/services/ContactUpdate https://myhost.com/zosConnect/services/ContactDelete <zosConnectService id="zcs3" serviceName="ContactCreate" serviceDescription=“Create" serviceRef="wolaKIXPHONE" dataXformRef="xformJSON2Byte"> </zosConnectService> <zosConnectService id="zcs4" serviceName="ContactUpdate" serviceDescription=“Update" serviceRef="wolaKIXPHONE" dataXformRef="xformJSON2Byte"> </zosConnectService> <zosConnectService id="zcs5" serviceName="ContactDelete" serviceDescription="Delete" serviceRef="wolaKIXPHONE" dataXformRef="xformJSON2Byte"> </zosConnectService> Pointer to section in XML that defines the “Service Provider,” which provides connectivity to the backend system Pointer to section in XML that provides information on how to do data transformation
- 50. © 2015 IBM Corporation 50 Audit (SMF) Interceptor The audit interceptor writes SMF 120.11 records with the following information captured: Liberty Profile z/OS z/OS Connect • System Name • Sysplex Name • Jobname • Job Prefix • Address Space Stoken • Arrival Time • Completion Time • Target URI • Input JSON Length • Response JSON Length • Method Name • Service Name • Userid Server Identification Section z/OS Connect User Data Section
Editor's Notes
- Exposing mainframe applications and services to mobile Exposing mainframe applications and data to mobile devices makes business sense, but how can you ensure that the critical connection of z Systems to mobile is as straightforward as possible? This session focuses on technologies that simplify the integration of z/OS applications such as CICS, IMS and WAS on z/OS with mobile applications. We examine the WebSphere Liberty z/OS Connect feature, which provides a simple, secure and standards-based interface to applications that must access z/OS assets. Additional technologies such as MQ, API Management and DataPower, which can further enhance integration, management and security also are covered.
- The "API economy” has changed how developers think about building apps, and how organizations deploy software in the cloud. Everywhere you look on the Web these days, it seems as if somebody’s launching new APIs. There are over 10,000 API documented on programmable web today… and is significantly increasing as we speak. Several years ago Jeff Bezos declared that all Amazon IT assets were to be exposed as APIs. Out of that “simple” declaration came an IT (and cultural) architecture that led to the stunning growth of Amazon Web Services, which is thought to be a billion-dollar business unit after only a few short years of growth. Perhaps even more impressive is the fact that, today, Salesforce.com generates more than half of its revenue through its APIs, not its user interfaces. Twitter is said to process 13 billion transactions a day through its APIs. Google is around 5 billion transactions a day. (Hotel map) New industries defined – Airbnb, Uber, etc
- Let’s look at the Cars.com mobile app as an example. Cars.com is a consumer of APIs, and has assembled several 3rd party apis together to form the base function of their cars app. For example, they use a Map Provider API to provide a “store locator function” APIs from a car dealer data aggregator for availability of certain makes and models. They use APIs from a Bank to offer Loan calculators and origination Auto insurance from an Insurance companies APIs And can imagine them using the new Xtify API from IBM to provide notifications, that a car they were looking for was now found.
- As the definition explains, the Web Economy is where companies [providers], expose their internal digital assets or service in the form of Web APIs to third party [consumers] with the goal of unlocking additional business value through the creation of new assets. <MAXX> Emphasize definition… Also… Re-sub-title – The API Economy lifecycle
- Businesses in various industries have developed “core competencies” over time, with supporting software functions and matching “brick and mortar” capabilities, such as banking, auto-dealership, healthcare providers, etc. These capabilities can be leveraged by exposing these functions as APIs. Many of these software functions reside in z Systems There are three key drivers for exposing these assets as APIs Reaching new customers and markets through partner applications and solutions that leverage these business capabilities Improving end-user experience with Mobile apps and/or with new system of engagement applications, possibly running in a cloud environment that access systems of record, and Improving consumability of existing services by making it easy to look up via catalog, and easy to set up through self-service registration, and improving governance of access to existing services by managing entitlement and gaining insight from access history
- Publishing an API for external consumption is not the same as Listing in the internal asset repository for development and maintenance, or Listing in runtime SOA Service Registry for use in Enterprise Service Bus (ESB) for routing, mediation and policy enforcement A business web site (as in this example, by Sabre) lists all the APIs offered by this business to its partners, external (and also internal) application developers. An API description includes not just the description of the business functions, interface for invoking the API, and detailed description of various information field, example on its use. The APIs are categorized and listed using associated categories for ease of look up. Additional details include various entitlement policies and offering levels.
- SOA efforts have been driven by developers’ productivity gain and enabling reuse of functions, i.e., focused on development of services. API Management, on the other hand, is driven by consumption of these services, i.e., improving consumability of these services for both external and internal developers of applications accessing these APIs, while also retaining control by the providers of these APIs. Improving consumability includes listing APIs in a browsable/searchable catalog and making it easy to register applications with the right entitlement level Retaining control includes not only enforcing entitlements and managing workloads, but also providing insight based on access history and accountability for chargeback. CAMS – Cloud, Analytics, Mobile and Social – are the enablers for new applications and services. This includes: Cloud – new applications, including by partners, accessing existing assets can be cloud based Analytics – can be used both to improve system of interaction addressing customer experience as well as to gain business insight Mobile – new forms of applications can be used in improving customer experience, and/or to deliver new services to end-consumers directly Social – helps to understand better consumers and deliver services in new ways
- Introducing IBM API Management: capabilities include Exposing business services securely as APIs to developer communities, and analyzing API usage Providing self-service API portals to external/internal app developers Managing & monitoring the entire API platform
- Key steps in Managing APIs Create, assemble and define an API Secure & scale the API Share with developers Manage growth & analyze results
- End-to-end Architecture and IT roles in exposing, and consuming z assets as APIs Three-tier Architecture: Development of enterprise services from existing z assets, making it easy to invoke these applications z application environments (CICS, IMS, WAS) provides tools and runtimes to develop and invoke Web and REST based services from applications based on COBOL and PL/I IT role (Bob) is knowledgeable about this SW stack Development and management of APIs exposing existing enterprise services Addressing consumption and governance of APIs Create an API , discover a suitable existing service, and assemble this API from this service Development of Mobile, Cloud or Third-party applications consuming APIs Browse catalog and identify APIs to consume Register an application that will consume a specific API at a specified entitlement level Use of developer portal to test APIs
- APIM capabilities for discovering z assets: Get a list of metadata maintained for various types of z based services (e.g., CICS or IMS, Web or REST services) Discover a service based on keywords and attributes from the deployed services in z System Import definition and configurations details of a service for creation and assembly of an API Matching z capabilities: Support for Web Services in CICS and IMS z/OS Connect for supporting REST services for all z Applications Discovery protocol support for both Web and REST services
- IBM API Mgmt provides the management platform, while IBM DataPower provides the API Gateway to enforce API security and control . IBM APIM sits on a server as a virtual appliance, while DataPower can be a virtual appliance or a physical appliance
- We start with a discussion that sets the context for the details that follow. At the very heart of this discussion is the idea of devices and systems using RESTful calls and JSON data to access the mainframe and the applications and data that resides there. REST and JSON are becoming more and more common in the world of mobile and cloud system access to systems of record. REST and JSON are briefly described here. A more detailed description is offered a bit later in this presentation. For REST and JSON to be effective, something has to be in place to recognize and handle the REST call and the JSON data. Key Point: z/OS Connect is designed to be a REST/JSON interface to a z/OS LPAR. z/OS Connect is software function written by IBM that runs inside an instance of WebSphere Liberty Profile z/OS, and uses existing connector technology to get to the backend systems. There is no charge for z/OS Connect; it is supplied as part of license entitlement to WAS z/OS, CICS or IMS.
- This chart is a follow-on to the point made at the end of the previous chart. This chart explains the business value of z/OS Connect. The bullet points on the right side of the chart summarize the value proposition of z/OS Connect. At the end of the day it’s about a manageable and simplified interface to the z/OS LPAR for mobile and cloud devices that use REST and JSON.
- This chart is intended to show the various solutions that IBM currently has to access System z Systems of Record. Note that several of these solutions will be moving towards have affinity with z/OS Connect and are moving towards integration. The intent if for z/OS Connect to become established as the reference architecture for exposing z/OS through RESTful services.
- As mentioned earlier, z/OS Connect is a no-charge software function that is part of your license entitlement for WAS z/OS, CICS or IMS. Each provides a delivery mechanism – Liberty and z/OS Connect will be supplied by WAS z/OS, CICS and IMS. Note: the Liberty and z/OS Connect for CICS will run inside a CICS region. It is intended to be used only inside CICS regions and not outside. The Liberty and z/OS Connect supplied by WAS z/OS and IMS look very similar on the surface, but for IMS the access mechanism is a JCA resource adapter and not the local adapters. To use the JCA resource adapter with IMS, a running copy of IMS Connect is required. For the purposes of this presentation the focus will be on WAS z/OS. That implies a Liberty Profile server instance with z/OS Connect enabled and configured. The implementation supplied with IMS is very similar, with the difference being the connectivity to IMS supplied as a JCA resource adapter that will talk to a running instance of IMS Connect. The CICS implementation is somewhat different in that the Liberty instance will run inside the CICS region, and the backend connectivity is provided through the JCICS interface of the CICS region. We mention these delivery mechanisms because we have seen some confusion created by this. The different delivery approaches tends to obscure the story of z/OS Connect and the value it brings. We thought it best to bring this point out early to clear any misunderstandings that may be present. This will allow us to focus back on z/OS Connect and what it provides. IMS specifics The IMS mobile solution is a no-charge offering that provides a RESTful endpoint to access IMS transactions. The solution comprises the service provider for z/OS Connect and a Windows-driven, Eclipse-based tooling platform for service creation and administration. Obtaining the service provider: For customers who already have WAS for z/OS Liberty Profile, the IMS service provider is downloadable as 'IMS Mobile Feature Pack' from within the Liberty repository as described here: https://developer.ibm.com/wasdev/downloads/#asset/features-com.ibm.ims.imsmobile-1.0 For customers who do not have WAS Liberty Profile, the IMS Mobile Feature Pack service provider is available as a component of IMS Enterprise Suite for z/OS Version 3.1.1, PID 5655-TDA, orderable from Shop zSeries. WAS LP is bundled with IMS ES for z/OS 3.1.1. Obtaining the IMS mobile tooling platform: Service creation and administration is handled through IMS Explorer for Development, downloadable from http://www.ibm.com/software/data/ims/downloads.html.
- This chart provides a little background on what “REST” is. As the chart shows, REST is built on the notion of using HTTP verbs (GET, PUT, POST, DELETE) along with the URI (the portion of the URL that comes after the host and port) to indicate the function to perform. The example above is suggesting a function that gets some information on a customer number. For this to work, both the client and the server much understand what functions are available and what URI formats are accepted. To assist in this, z/OS Connect has a discovery function that allows developers to understand what services are available through a z/OS Connect instance, and what the details of those services are. RESTful services are growing in popularity because it’s relatively simple to implement.
- JSON is a way of representing data in a name/value pair manner. The chart above shows a simple example of JSON for a customer data record – name, age, and address. When a client (smart phone, tablet, browser, etc.) sends in a REST call with data, the JSON associated with the request (or response) is serialized and appended to the end of the URI. The data flows back and forth between client and server in this fashion. That means the “state” of the interaction is maintained with the flows going back and forth. That means there’s no affinity requirements – that is, there’s no requirement that a client talk to the same server instance each time. A cluster of server instances can exist and, provided they can access the same data and provide the same functions, it doesn’t matter if the client goes to server A, B or C. The lack of affinity routing requirements means the requests are stateless (state is carried with the request; not maintained outside the request). Stateless requests are very easy to manage in a network topology; stateful requests require stateful routing or state replication. REST and JSON avoids the need to worry about stateful routing. Anticipated Question Answered: yes, z/OS Connect instances can be clustered, either on the same LPAR or across LPARs. The important thing is that all the z/OS Connect instances in a cluster operate identically, and have access to the same backend systems. The way to make multiple instances of z/OS Connect operate identically is to make sure they run with the same configuration information. On z/OS with Parallel Sysplex the ability to insure shared data in the background is quite achievable. That talk about state and affinity routing was a bit of a detour from the main point about JSON as a means of representing data. JSON tends to be favored over XML because it is a bit lighter weight. Both XML and JSON need to be parsed (that is, the data extracted so it can be understood and worked on). Parsing JSON is a bit easier than parsing XML.
- One of the concerns we’ve heard expressed is this – “Does z/OS Connect expose all my backend CICS programs to Internet?” And the answer to that is an emphatic “No!” Key Point: z/OS Connect will only expose those services you code in the Liberty Profile configuration file. z/OS Connect does not scan your z/OS LPAR looking for programs to expose. z/OS Connect is only as smart as the configuration file information it operates from. You control what programs and applications are exposed as services through z/OS Connect. That’s what this chart is saying … z/OS Connect operates from the information provided in the Liberty Profile configuration file, which is the server.xml file. You control what goes into that file. Only those backend programs you wish to expose as services will be discoverable and usable through z/OS Connect.
- We mentioned earlier how there is a “discovery function” provided with z/OS Connect. This provides developers a means of determining what services an instance of z/OS Connect exposes, as well as details about a given service. Sending in a URI with just /services will return a JSON list of services and their service URLs. A developer would use this to get an idea what services are configured in the server.xml for that instance of z/OS Connect. If a service is of interest, they can send in a second URL, this one asking for details on the specific service. That will return a JSON object with details about the service. It is also possible to query for and receive the JSON schema for the service … both the request JSON schema as well as the response JSON schema. With that, a developer can develop the client-side code to invoke and make use of a service exposed through z/OS Connect.
- We mentioned earlier how there is a “discovery function” provided with z/OS Connect. This provides developers a means of determining what services an instance of z/OS Connect exposes, as well as details about a given service. Sending in a URI with just /services will return a JSON list of services and their service URLs. A developer would use this to get an idea what services are configured in the server.xml for that instance of z/OS Connect. If a service is of interest, they can send in a second URL, this one asking for details on the specific service. That will return a JSON object with details about the service. It is also possible to query for and receive the JSON schema for the service … both the request JSON schema as well as the response JSON schema. With that, a developer can develop the client-side code to invoke and make use of a service exposed through z/OS Connect.
- Here we’ll introduce some terminology that’s used with z/OS connect – a “Service Provider.” A service provider is simply the functional implementation that gets the request to a backend system like CICS or IMS. In the previous charts we showed the local adapters used to access a single CICS region. That was an example of a single service provider. But you are not limited to a single service provider; you may configure multiple service providers if you wish. For example, if you wished to expose programs in CICS and IMS, you would configure two service providers – one for accessing CICS (using the local adapters), and one for accessing IMS (which is implemented with a JCA resource adapter that communicates with a running instance of IMS Connect to access IMS). If you had two CICS regions you wished to communicate with, you’d configure two service providers in the instance of z/OS Connect – one to access CICS region A and another to access CICS region B. Note: the service provider interface is documented so that you may write your own service provider if you wish. You are not limited to just those supplied with z/OS Connect.
- The earlier chart showed a bit of XML that pointed to a data transform definition. Here we’re showing you what that data transformation XML might look like. On the surface this looks complicated but in reality it’s not – it’s really just telling z/OS Connect where to find the “bind” files and the JSON schema. Bind files provide the data field conversion information. They are produced by running a supplied utility (based on the WSBIND utility supplied by CICS) to transform program data definitions structures (for example, COPYBOOK for COBOL) into a file that allows z/OS Connect to understand the JSON-to-COPYBOOK conversion pattern. The XML above is illustrating how you tell z/OS Connect where the bind files are located, the suffix used for those bind files, as well as the location and suffix used for the JSON schema files. With that information available, z/OS Connect can read in the bind files and perform JSON conversion. The converted data – now in something other than JSON – can be passed back to the backend program for processing. The backend program doesn’t need to know anything about REST or JSON … z/OS Connect is doing all that work in its role as a service interface to backend systems.
- This is emphasizing the point made on the earlier chart – the bind files are created by using a program originally developed for the CICS web services function. This utility reads in COPYBOOK (or other data structures) and produces the bind file and JSON schema. The gray box on the chart is simply showing the JCL that might be used to run this utility program. Note: you may either use the DFHLS2JS program supplied with the CICS Feature Pack, or use the utility supplied with z/OS Connect.
- Another functional element of z/OS Connect is something called an “Interceptor,” which is a callout point that may be invoked for each request and invoked again for each response. It’s optional – you aren’t required to use the interceptor function – but if you wish to have callout processing performed for requests and responses you have this capability present. Two provided interceptors are available – one is for security, which will work with SAF to perform authorization (EJBROLE) checks; and another for auditing, which will work with SMF to cut activity records. You can configure global interceptors that apply to all defined services, or you may define interceptors that apply to just those you wish them to apply to. For global interceptors you can ‘opt out’ of those global interceptors for specific services if you wish. Note: like Service Providers, this Interceptor interface is documented and you may write your own interceptor code if you wish.
- When the backend system is CICS and the local adapter support is used, it implies installing into the CICS region the Optimized Adapter support. This is not difficult to do; but it is necessary so the CICS region has the ability to communicate using the optimized local adapters. The picture is showing the basics of the optimized local adapter function in the CICS region: The Task Related User Exit (TRUE) provides the low-level function support for the optimized adapters. This TRUE must be active in the CICS region to communicate across the optimized local adapters. The BBO$ link server is a long running task that handles the calls from z/OS Connect prior to invoking the target program. This is what makes the optimized local adapter calls transparent to the target program – BBO$ shields the target from the local adapter specifics. BBO$ starts an instance of BBO# for each call. The reason this is separate from BBO$ is because the optimized local adapters supports the assertion of identity. When the thread ID from Liberty is asserted over, then each instance of BBO# is run under the identity of the asserted ID. When thread ID from Liberty is not asserted, then BBO# is run under the same ID as BBO$ and the instance is re-used. The final link in this chain is an EXEC CICS LINK call to the target program from the BBO# invocation task. To the target program this looks like any other CICS program calling it. It has no knowledge of the optimized local adapters being part of the picture. The WP101490 Techdoc at ibm.com/support/techdocs provides more information on WebSphere Optimized Local Adapters.
- Another use-case for z/OS Connect and the optimized local adapters is for exposing “batch as a service.” This is possible because the local adapter APIs support a “listen mode” API that will put a batch program into a wait state until someone calls. That “someone” can be z/OS Connect calling to the batch. To avoid updating all your batch programs, you can write a batch program that uses the local adapter APIs to “host a service” (go into a wait state), then have that program do a dynamic or static link to another program. That way the linked program doesn’t have to have any knowledge of the local adapter APIs. Upon return the first batch program would loop back and call the “host a service” API again. It would keep doing that for as long as you wished z/OS Connect to have a backend batch program exposing batch as a service.
- z/OS Connect may work with IMS as well, though in the case of IMS it will use a JCA resource adapter to connect to IMS, not the local adapters. The JCA resource adapter will make a network call to a running copy of IMS Connect, which will then turn and use OTMA to get into the IMS region. Everything else about z/OS Connect is the same as we discussed earlier. The only difference is the “service provider” being a JCA resource adapter. (And in truth the optimized local adapters also use a JCA resource adapter, but a different one. The difference is really the implementation below the JCA API layer – for the optimized local adapters code is invoked that does a cross-memory call; for IMS code is called that makes a network call to IMS Connect.)
- Now let’s take a peek inside z/OS Connect to get a feel for how it works.
- If we wanted to quantify those benefits we do have a view….this is from an external analyst – studying… And the more use messaging is put to…the greater the benefits
- So what does MQ offer? – messaging middleware – an interface layer helping to isolate applications connecting across different platforms from the mainframe to the mobile…
- As we just covered MQ provides guaranteed, assured messaging that provides transactional integrity with the speed and security that any enterprise will need for mission critical applications. E.g., transactions at a bank, money movement in finance sector, retailer processing of payment card or purchase details, border security and immigration processing, moving data through factories and in and out of ERP systems MQ enables you to connect applications and services together with valuable qualities-of-service. Applications can exchange information without tying themselves up – just like email where people communication a-synchronously. MQ has been doing all this for years – we have 10000+ customers who have built their businesses around it – and rely on it not just every day – but every second. It helps their businesses be more flexible, more reliable and more secure. Deployments on platforms like System z with its coupling facility helps customers to be robust and recover from failures without interrupting their processing – and we have hundreds if not thousands of partners and skilled practioners to support these deployments – as well as big teams in IBM enhancing the product and delivering major new updates – such as the new IBM MQ V8.
- In april 2014 IBM announced our latest major new version of MQ – V8 to be available on all major platforms this quarter. As we have covered – by using messaging solutions like MQ, businesses can keep their applications simple, while delivering data from pretty much any source to any other endpoint, helping the business to streamline, cutting costs and time, and meeting the changing needs of the business. So although thousands of customers are already current with MQ – what can they expect in the new V8 release? Well MQ is broadly common across bother distributed and z/OS platforms but there are some distinctions – on distributed there are updates focused on helping customers to scale their workload deployments – supporting larger workloads, more messages, more queues, and doing that without increasing the tasks on the administration and operation team. Security is of course high on everyone’s agenda and there have been big changes there too – both to enhance security and to ensure it is easier to use and manage. And there are some new functions as well – in support of new standards like JMS2.0 – plus exciting news for customers on IBM I – with MQ AMS available on that platform for the first time. For z/OS it gets the benefit of a lot of the same updates but also some specific new features to really exploit the platform capabilities – helping deployments to scale better, perform better, and with easier administration, boosting reliability and robustness. And of course with z being critical to so many businesses, security again is featured with stronger SHA-2 encryption. Plus as a bonus customers on V8, as well as V7 can now connect MQ clients on other platforms directly to the z/OS MQ without the additional CAF charge – this will help customers choose how to connect and exploit the data movement and business needs far more flexibly.
- By consuming APIs to assemble their App, Cars.com… Can focus on their core competence and value add, rather then reinventing common capabilties Sees Quicker time to market, decreases cost and speeds up their cars.com app development and delivery Drives innovation, from others, into their app (like, perhaps the notifications from Xtify) Perhaps the insurance company offers value to their affiliates (which cars.com is now part of) by marketing the cars.com app to their insurance customers
- Expands into new customer bases and niches that the bank would normally not reach on their own Expands their brand and brand loyalty – you think about google when you see their maps appear in apps, perhaps you will think of “the bank” when you see their signature mortgage calculator And now you have third parties (not necessarily external) innovating with your content in ways you haven’t imagined and you are now monetizing those sources – across a wide array of app, running on a wide array of platforms
- The primary configuration file for Liberty Profile is server.xml. It is in this configuration file that updates are made to enable the z/OS Connect function and to configure the behavior of z/OS Connect. The chart above is showing an example of a “HelloWorld” URL coming into z/OS Connect and the configuration that would be in place to support responding to the request: The <featureManager> section of server.xml is used to tell the instance of Liberty what functional features you wish to be loaded. z/OS Connect is loaded with the zosConnect-1.0 feature. z/OS Connect uses the cross-memory local adapters function to access backend services like CICS and Batch, and to enable that function requires the zosLocalAdapters-1.0 feature. The next section is what tells z/OS Connect about the HelloWorld service. The serviceName= value is what is matched to the URI. The serviceRef= value is what points to the section of XML that defines how the backend system will be accessed to deliver the service. That section defines the local adapter “register name” and “service name” to be used when the HelloWorld service is requested by a client. The register name is the cross-memory connection to, in this example, a CICS region. The service name is the program back in CICS that will be called. Without getting too deep into configuration XML, the main point here is that the configuration spells out what services are exposed, and how the backend system is accessed. In this “HelloWorld” example we illustrated the URL, the service definition and the backend local adapter definitions. Those aren’t the only configuration updates needed, but that’s a good start to show the essential elements.
- The previous chart showed one configured service. This chart is illustrating the point that you may have multiple configured services. Here we’re showing three configured services – Create, Update and Delete contact information. Three service definitions are configured in the server.xml … one for each service to be exposed. In addition, the example above is showing that all three are going to make use of the same serviceRef=, which is the local adapter connector to the backend CICS. That means Create, Update and Delete are all hosted in the same CICS region. (You are not limited to a single CICS region; you can configure services in multiple CICS regions if you wish.) Further, this example is showing dataxform=, which is a pointer to XML (not shown on this chart, but we’ll show it on an upcoming chart) that defines how the JSON data will be converted to the format needed by CICS and the backend program. This illustrates another important function of z/OS Connect – the ability to transform data back and forth.
- This chart illustrates the SMF record information to be written for each request. This will produce an SMF 120.11 record, which is different from the traditional WebSphere Application Server z/OS 120.9 record.