Using CICS with DB2 pureXML, Part 2: Perform advanced XML storage and retrieval through CICS Web services

More scenarios and use cases

This article is the second part of a series of articles. The first article focused on augmenting CICS® Web services with two general purpose routines (pipeline handlers) that support two scenarios to store and retrieve XML in DB2(R) pureXML. This second part introduces two more scenarios: a service request scenario and a service response scenario. The service request scenario shows how a custom pipeline handler can be introduced to further enhance CICS Web services to store XML data in relational form or in XML form after extracting the XML that represents the business data from the SOAP message. The service response scenario shows how a custom pipeline handler can be introduced to publish relational data as XML, and how XML data can be modified directly through SQL before returning the data in a service response. This article also illustrates how stored XML data can be accessed as relational data through a view for easy placement in a CICS COMMAREA or container. Some sample COBOL source code is included in the Downloads section.

Share:

Daniel Millwood (millwood@uk.ibm.com), Software Engineer, I.B.M.

Daniel MillwoodDan Millwood is a Software Engineer in IBM Software Group in Hursley, where he works on the CICS Services and Technologies team. During his 15 years at IBM, Dan spent 7 years as a developer on WebSphere MQ for z/OS, then he worked as a developer on the platform messaging component of WebSphere Application Server before he joined the CICS development organisation. Dan is a keen photographer and also enjoys hiking, kayaking, and playing soccer.



Susan Malaika (malaika@us.ibm.com), Senior Technical Staff Member, IBM

Susan Malaika photoSusan Malaika works in IBM's Information Management Group. She specializes in XML and Web technologies, including Grid computing. She has published articles and co-edited a book on the Web. She is a member of the IBM Academy of Technology.



04 November 2010

Also available in Chinese Portuguese

Introduction

CICS Web services support enables you to access CICS applications through web services. CICS applications can also invoke web services. CICS supplies various handlers, including pipeline and application handlers, to manipulate the incoming and outgoing web services messages. You can write your own handlers, too. This article assumes that you are familiar with CICS Web services.

DB2 pureXML enables the storage of XML in XML collections (columns). The individual XML elements and attributes in the stored XML can be indexed and manipulated in application programs such as Java, COBOL, or C, through XPath and SQL/XML. You can also view the stored XML in relational form.

The benefits of storing and retrieving XML directly include the following:

  • The system is simpler to design: No (or few) data normalizations required.
  • The system is speedier to develop: Fewer mappings between the incoming and outgoing data and the stored data.
  • The system is faster to execute: Fewer relational joins and less XML shredding, which consumes CPU.
  • The system is quicker to evolve: Fewer database changes needed, because as long as the XML is well-formed, it can be stored in the database (and optionally validated)
  • The system is easier to understand: The data structures are consistent across the boundaries of the system and the database.
  • The system is straightforward to prototype: Less customization is required, and the database design is simple
  • The system integrates smoothly with web technologies: Web technologies are XML-based.

DB2 pureXML stores XML data in parsed form. Thus, in many cases you don't need to repeatedly parse the same XML in the middle tier, which is CPU intensive. Instead you can use declarative languages, such as XPath or SQL/XML, to manipulate the already parsed XML, as shown in Figure 1.

Figure 1. Parse once—access many with DB2 pureXML
Client and protocol sending XML on left of CICS WebSphere server, and DB2 pureXML sending XML on the right of the server

This article describes the following:

Reviewing the scenarios

The first article in this series, "Using CICS with DB2 pureXML, Part 1: Perform basic XML storage and retrieval through CICS Web services" introduced two scenarios. Scenario 1 in that article stored an incoming web service XML message, including the SOAP header, into a DB2 XML column, as shown in Figure 2.

Figure 2. Service request: Using DB2 pureXML to log inbound messages
Exec CICS gets container into XML using pipeline handler, Exec SQL inserts into Redbook, and DB2 logs SOAP messages

This article develops Scenario 1 further by describing the following scenarios:

Scenario 1A
Extracts the business data from the SOAP message using SQL/XML, and then stores the XML
Scenario 1B
Converts (shreds) the XML into relational form using SQL/XML, and stores it

Scenario 2 in the first article retrieved XML data stored in DB2, which included the SOAP header, and returned it in a response to a web service request, as shown in Figure 3.

Figure 3. Service response: Using DB2 pureXML to create outbound messages
Exec CICS gets container into XML using pipeline handler, Exec SQL selects XML serialize

This article develops Scenario 2 further by describing the following scenarios:

Scenario 2A
Updates XML data through a capability of DB2 10 for z/OS
Scenario 2B
Uses SQL/XML to publish relational data as XML and to return the resulting XML in a response to a web service request.

Introducing the new scenarios

Following are the new scenarios in this article.

CICS service request
The service request scenarios, Scenarios 1A and 1B, give examples of ways in which the data in an inbound web service request message can be accessed and manipulated using pureXML. The SQL is provided that extracts the business data from the body of a SOAP message and then stores the business data in DB2. In Scenario 1A, the business data is stored as XML. A variation is also discussed that enables the data stored as XML to be accessed as relational. Scenario 1B offers an option in which the XML is shredded to enable the data to be stored as relational.
CICS service response
Service response Scenario 2A describes how XML data can be updated through a capability of DB2 10 for z/OS. Service response Scenario 2B illustrates how relational data can be returned as XML through a capability of DB2 8 z/OS. This article's example uses this to construct a web service response message to be returned from the web service.

Figure 4 shows how each of the new scenarios flows:

  • Scenario 1A processes the service request and stores the XML intact into an XML storage table on the DB2 server.
  • Scenario 2A retrieves the stored XML, modifies it intact, and outputs a service response.
  • Scenario 1B processes the service request and stores it as relational data on the DB2 server.
  • Scenario 2B retrieves the stored relational data and outputs a service response in XML format.
Figure 4. Service request and response flow
Service request and responses on left, goes through 4 different scenarios (2 input, 2 output) on its way to XML or DB2 storage

Table 1 shows a scenario summary for the scenarios in both articles. Article 1 refers to the first article in the series. Article 2 refers to this article. DB2 z/OS version indicates the version of DB2 that provides the capability to support the scenario.

Table 1. List of CICS Web services and DB2 pureXML scenarios
Article (Part 1 or Part 2)DB2 z/OS versionScenario nameDescription
19Scenario 1: Request - XML with SOAP headerStore incoming XML in DB2 pureXML with SOAP header
29Scenario 1A: Request - Modified XML (Business data extract without SOAP header)Store incoming XML in DB2 pureXML by extracting the business data using SQL/XML to remove the SOAP header. Also, access the stored XML as relational through SQL/XML views
29Scenario 1B: Request - RelationalStore incoming XML as relational in DB2 using SQL/XML to shred the XML
19Scenario 2: Response - XML with SOAP headerRetrieve the stored XML in DB2 pureXML and return it as a response
210Scenario 2A: Response - Modified XMLRetrieve and modify the stored XML in DB2 pureXML and return it as a response using DB2 10 for z/OS capability
28Scenario 2B: Response - RelationalRetrieve the stored relational data and return it as a response using SQL/XML to publish the relational data as XML

The benefits of using DB2 capabilities to manipulate XML include the following:

Manipulating complex XML
If the inbound XML data is complicated, with multi-dimensional nested structures, then accessing the data using XPath queries might be simpler than by using the CHANNEL and CONTAINERs interface that the CICS supplied application handler provides.
Parse-once approach
If the data needs to be persisted in DB2, then less CPU is likely to be used if all XML manipulations are performed in DB2.
Log of incoming messages
Using some of the techniques described here, a query-able log of the incoming messages is maintained, making it simpler to track what is happening in the system.

Understanding the CICS Web service configuration

This section of the article explains the configuration of the CICS Web service and where the pureXML capabilities are introduced. CICS Web services use a number of CICS resources such as a URIMAP, a PIPELINE containing one or more handlers, a WEBSERVICE resource, and so on. If you are unfamiliar with CICS Web services, it is recommended that you read introductory materials on the subject before continuing with this article. In particular, it is assumed that you are familiar with the CICS PIPELINE and pipeline handlers. See the Resources section for suitable documents.

When a web service message (a SOAP message) is passed through a CICS pipeline, zero or more handlers can access the message and make decisions based on its contents. CICS provides some of these handlers for security, distributed Units of Work (UOWs), and so on, as shown in Figure 5.

Figure 5. CICS Web services handlers
Request in goes through optional, terminal and application handlers to run business logic and reply out

After these handlers have run, the message is passed to a terminal handler program. The terminal handler is responsible for processing the SOAP message.

You can write your own handlers, such as the general purpose terminal handler WEBINST described in the first article. However, CICS provides a SOAP handler that performs a number of checks on the inbound SOAP message to ensure that it is compliant with the SOAP specifications and returns the correct SOAP faults in error situations. For this article, use the supplied SOAP handler and gain the benefits it provides, including the capability to modify the CICS user ID and trans ID under which the business logic executes.

After the CICS-supplied SOAP handler has run, control is passed to an application handler. The application handler typically converts the body of the SOAP message into data structures suitable for use in a standard CICS program, and then links to that program. CICS supplies an application handler called DFHPITP that does the conversion. Rather than using DFHPITP to convert the XML into a COMMAREA structure or a CHANNEL with CONTAINERS, create an application handler named PUREXML(A or B) to insert the data into DB2. The application handler can then link to business logic, which can perform queries and updates on the data through SQL commands.

Listing 1 shows an example of the pipeline configuration file.

Listing 1. CICS pipeline configuration file example
<?xml version="1.0" encoding="EBCDIC-CP-US"?>
  <provider_pipeline xmlns="http://www.ibm.com/software/htp/cics/pipeline">
    <service>                                                  
      <terminal_handler>                                           
        <cics_soap_1.1_handler/>                                      
      </terminal_handler>                                          
    </service>                                                 
    <apphandler>PUREXMLA</apphandler>                               
</provider_pipeline>

Scenario 1A: Store business data from incoming XML in DB2 pureXML

The DB2 table to store the XML is defined as shown in Listing 2.

Listing 2. DB2 table definition for storing XML
CREATE TABLE REDBOOK.SOAPBODY (
  ID   ROWID NOT NULL GENERATED ALWAYS,
  BODY XML)
CCSID EBCDIC
IN DATABASE REDBOOK;

The SOAP body contents that are included in the inbound message, such as the business data, are stored in XML format in the DB2 pureXML column called BODY. An ID field of type ROWID is also included. When the XML data is stored, it can be useful to have a key to the data, so that if the business logic needs to access the inbound XML later, it has an easy way to find it. The ROWID enables this capability.

When the request arrives into the CICS application handler, the entire SOAP envelope is read from the DFHREQUEST container into a variable called XMLDATA. Once the SOAP message is in memory, SQL is used to extract the contents of the body of the message (the business data) and store it into the table REDBOOK.SOAPBODY in the BODY column,, as shown in Listing 3.

Listing 3. SQL to store business data from incoming XML message as XML (without the SOAP header)
EXEC SQL
  SELECT ID INTO :WS-ROWID
    FROM FINAL TABLE(
    INSERT INTO REDBOOK.SOAPBODY ( BODY )
       SELECT XMLDOCUMENT ( X.BODY )
         FROM XMLTABLE(
         XMLNAMESPACES
       ('http://www.SWITCHI.com/schemas/SWITCHIInterface' AS "datans",
        'http://schemas.xmlsoap.org/soap/envelope/' AS "soapns"),
        '$i/soapns:Envelope/soapns:Body'
        PASSING                                            
         XMLPARSE(DOCUMENT :XMLDATA STRIP WHITESPACE) AS "i"
         COLUMNS
           "BODY" XML PATH 'datans:SWITCHOperation' ) AS X)
END-EXEC.

DB2 generates the ROWID column content when the SOAP body is inserted into the table. The SQL statement selects the ROWID and stores it in a variable called WS-ROWID. This variable can then be passed to any business logic that needs to access the stored SOAP body. You might need to apply the fix to APAR PM25203 to use the ROWID in this way.

Note: The example in this article works with the entire message in the DFHREQUEST container. Although CICS has extracted the body of the message and provided it in a container called DFHWS-BODY, DB2 does not understand the data in the container on its own as valid XML. This is because CICS passes through any namespaces declared in the SOAP envelope of the inbound request in another container called DFHWS-NAMESPACES. If the data in DFHWS-BODY refers to these namespaces, an XML parser is likely to assume they are missing. In the case of DB2, an SQL error is produced, and the data cannot be parsed.


Scenario 1A variation: Access the stored XML as relational

While the data stored in Scenario 1A can be accessed directly as XML, you can also create relational views of the data. To do this, create a VIEW, and map the columns in the VIEW to the components of the XML message that are required. In the example, the inbound SOAP request message contains data associated with a customer account. Three pieces of information are taken from the SOAP message and made available through a VIEW called ACCVIEW: the account number, the account type, and the account balance. The DB2 administrator creates the VIEW while setting up the CICS Web service. Listing 4 shows how to create the view.

Listing 4. DB2 view definition for relational data (derived from the incoming XML message)
CREATE VIEW ACCVIEW(ACCOUNTNUM, ACCOUNTTYPE, BALANCE) AS
   SELECT X.* FROM REDBOOK.SOAPBODY RED, XMLTABLE(
    XMLNAMESPACES('http://www.SWITCHI.com/schemas/SWITCHIInterface' AS "datans"),
    '$acc/datans:SWITCHOperation/datans:account_details'
    PASSING RED.BODY as "acc"
    COLUMNS
            "ACCOUNTNUM"  CHAR(8) PATH 'datans:account_number',
            "ACCOUNTTYPE" CHAR(1) PATH 'datans:account_type',
            "BALANCE"    CHAR(8) PATH 'datans:balance') AS X;

At runtime, provide an application handler that is driven from the CICS-supplied SOAP handler. The application handler inserts the SOAP message into DB2. The data can then be accessed through the VIEW using a typical SQL query, as shown in Listing 5.

Listing 5. SQL to access XML data as relational through the view
EXEC SQL
  SELECT BALANCE FROM ACCVIEW WHERE ACCOUNTNUM = '12345678'
END-EXEC.

Scenario 1B: Store incoming XML as relational in DB2 pureXML

The DB2 table used in Scenario 1B is shown in Listing 6.

Listing 6. DB2 table definition for relational data (derived from the incoming XML message)
CREATE TABLE REDBOOK.ACCOUNT (
  ID   ROWID NOT NULL GENERATED ALWAYS,
  ACCOUNTNUM  CHAR(8),
  ACCOUNTTYPE CHAR(1),
  BALANCE     CHAR(8))
IN DATABASE REDBOOK;

DB2 parses the inbound request message, and certain components of the message are extracted and stored in columns within the table. As in Scenario 1A, when the request arrives into the CICS application handler, the entire SOAP envelope is read from the DFHREQUEST container into a variable called XMLDATA.

Next, the SQL call extracts specific fields from the inbound message and stores them in the REDBOOK.ACCOUNT table, as shown in Listing 7.

Listing 7. SQL to store incoming XML message as relational
EXEC SQL
  SELECT ID INTO :WS-ROWID
  FROM FINAL TABLE(
    INSERT INTO REDBOOK.ACCOUNT
         (ACCOUNTNUM, ACCOUNTTYPE, BALANCE)
       SELECT X.ACCOUNTNUM, X.ACCOUNTTYPE, X.BALANCE
         FROM XMLTABLE(
          XMLNAMESPACES
           ('http://www.SWITCHI.com/schemas/SWITCHIInterface' AS "D",
            'http://schemas.xmlsoap.org/soap/envelope/' AS "S"),
          '$i/S:Envelope/S:Body/D:SWITCHOperation/D:account_details'
          PASSING
           XMLPARSE(DOCUMENT :XMLDATA STRIP WHITESPACE) AS "i"
          COLUMNS
            "ACCOUNTNUM"  CHAR(8) PATH 'D:account_number',
            "ACCOUNTTYPE" CHAR(1) PATH 'D:account_type',
            "BALANCE"     CHAR(8) PATH 'D:balance') AS X)
END-EXEC.

As part of the same SQL call, the ROWID value of the inserted ROW is returned into a variable called WS-ROWID. Once the SQL call is executed, the ROWID value stored in variable WS-ROWID is placed in a CICS container, and an EXEC CICS LINK call is made to the program containing the business logic. The business logic program can access the newly inserted data from DB2 by selecting it using the passed ROWID value, as shown in Listing 8.

Listing 8. SQL to select stored relational data
EXEC SQL
  SELECT ACCOUNTNUM, ACCOUNTTYPE, BALANCE
  INTO :WS-ACCNUM, :WS-ACCTYPE, :WS-BALANCE
  FROM REDBOOK.ACCOUNT
  WHERE ID = :WS-ROWID
END-EXEC.

Scenario 2A: Retrieve and modify stored XML

In DB2 10 for z/OS, you can modify XML directly using SQL. You can add, modify, or delete XML nodes directly by specifying the appropriate XPath in the XMLMODIFY keyword. Listing 9 shows how to modify the value of the account_balance.

Listing 9. SQL to modify stored XML data
EXEC SQL
UPDATE REDBOOK.ACCOUNT set info = XMLMODIFY(' 
  REPLACE VALUE OF NODE /account_details/account_balance
 WITH "1000000.00"')
 WHERE ID = :WS-ROWID
END-EXEC

With the XMLMODIFY keyword, you can make changes to stored XML to re-format the stored data to suit the required output message structure.


Scenario 2B: Retrieve and publish stored relational data

Scenario 2B shows how to create XML that includes relational data. For the purposes of the example, create the same web service response message used in Scenario 1B. The WSDL that describes the web service is the same WSDL used in the first article on CICS and DB2 pureXML. The WSDL is very simple. The response message contains the same elements as the request message.

In the example for Scenario 1B, the request message was shredded into relational data and stored in DB2 before a business logic program was called. The business logic accessed the stored relational data from the request message by way of a ROWID value that it received. The business logic modified the balance of the account.

Back in the application handler, create XML that includes the updated balance alongside the other values required for the response message. Use the ROWID again to find the data to return. When writing an application handler, CICS expects that the container DFHWS-BODY will contain the body of the SOAP response message when the application handler completes its processing. Therefore, you need to write an SQL call that creates a SOAP body element, and within that element, you need to create the business data to be returned.

Listing 10 shows the SQL to create the example SOAP body. The created XML is placed in a variable called XMLREPLY.

Listing 10. SQL to publish relational data as XML
EXEC SQL
  SELECT
    XMLELEMENT( NAME "soapenv:Body",
        XMLNAMESPACES
          ('http://www.SWITCHI.com/schemas/SWITCHIInterface' AS "p0",
           'http://schemas.xmlsoap.org/soap/envelope/' AS "soapenv"),
      XMLELEMENT( NAME "p0:SWITCHOperationResponse",
        XMLELEMENT( NAME "p0:account_details",
          XMLELEMENT( NAME "p0:account_number", ACC.ACCOUNTNUM),
          XMLELEMENT( NAME "p0:account_type", ACC.ACCOUNTTYPE),
          XMLELEMENT( NAME "p0:balance", ACC.BALANCE)
        )
      )
    )
    INTO :XMLREPLY
    FROM REDBOOK.ACCOUNT ACC
    WHERE ID = :WS-ROWID
END-EXEC.

Note: When testing this scenario, you might find that the XML that DB2 creates begins with an encoding statement like this: <?xml version="1.0" encoding="IBM285"?>. CICS does not expect an encoding statement in the DFHWS-BODY container. Therefore, when the EXEC CICS PUT CONTAINER call is made in the COBOL program PUREXMLB, to put the SOAP body of the reply into the DFHWS-BODY container, the code puts the data after the encoding statement.


Testing the new scenarios

The first article provides clear instructions to test a CICS Web service. Where appropriate, refer to that article for information on testing the web services created in this article. Otherwise, complete the following steps to test the new scenarios.

Step 1 — Create the CICS pipeline configuration files

To create the CICS pipeline configuration files, complete the following steps:

  1. Copy the pipeline configuration files shown in Listing 11 to UNIX System Services (USS) as /u/user/config/AdvancedScenario1A_pipeline.xml.
Listing 11. CICS pipeline configuration file for Scenario 1A
<?xml version="1.0" encoding="EBCDIC-CP-US"?>
  <provider_pipeline xmlns="http://www.ibm.com/software/htp/cics/pipeline">
    <service>
      <terminal_handler>
        <cics_soap_1.1_handler/>
      </terminal_handler>
    </service>
    <apphandler>PUREXMLA</apphandler>
</provider_pipeline>
  1. Copy the pipeline configuration files shown in Listing 12 to UNIX System Services (USS) as /u/user/config/AdvancedScenario1B_pipeline.xml.
Listing 12. CICS pipeline configuration file for Scenario 1B and Scenario 2B
<?xml version="1.0" encoding="EBCDIC-CP-US"?>
  <provider_pipeline xmlns="http://www.ibm.com/software/htp/cics/pipeline">
    <service>
      <terminal_handler>
        <cics_soap_1.1_handler/>
      </terminal_handler>
    </service>
    <apphandler>PUREXMLB</apphandler>
</provider_pipeline>

Step 2 — Create and install CICS resources

The zip file provided in the Download section contains the COBOL source code for the application handlers used in this article. The zip file contains the handlers PUREXMLA and PUREXMLB. Both handlers link to COBOL business logic programs called PUREBUSA and PUREBUSB respectively. Complete the following steps to create and install the CICS resources:

  1. Compile and link all four programs using the integrated DB2/CICS/COBOL compiler. The JCL to compile the programs is included in the zip file. Tip: Examine the compiler and pre-compiler options specified in the supplied JCL to ensure that the supplied options are compatible with the options you usually use.
  2. Bind the DB2 plans by creating and installing the following CICS resources in your region:
    • PIPELINE(PUREXMLA) CONFIGFILE(/u/user/config/AdvancedScenario1A_pipeline.xml) SHELF(/u/user/shelf)
    • URIMAP(PUREXMLA) USAGE(PIPELINE) PIPELINE(PUREXMLA) HOST( * ) PATH(/pureXML/AdvancedScenario1A)
    • PROGRAM(PUREXMLA) DATALOCATION(ANY)
    • PROGRAM(PUREBUSA) DATALOCATION(ANY)

    The following CICS resources are required for Scenario 1B and Scenario 2B:

    • PIPELINE(PUREXMLB) CONFIGFILE(/u/user/config/AdvancedScenario1B_pipeline.xml) SHELF(/u/user/shelf)
    • URIMAP(PUREXMLB) USAGE(PIPELINE) PIPELINE(PUREXMLB) HOST( * ) PATH(/pureXML/AdvancedScenario1B)
    • PROGRAM(PUREXMLB) DATALOCATION(ANY)
    • PROGRAM(PUREBUSB) DATALOCATION(ANY)

    The CICS resource TCPIPSERVICE(PUREXML) PORT(xxxxx) PROTOCOL(HTTP) is required for all the new scenarios.

    DB2 requires the following CICS resources for all new scenarios:

    • DB2ENTRY(PUREXML) ACCOUNTREC(TXid) AUTHTYPE(Userid) DRollback(Yes) PLAN(PUREXML)
    • DB2TRAN(PUREXML) ENTRY(PUREXML) TRANSID(CPIH)

Step 3 — Test the web services

Sample WSDL for the web services is provided in the zip file.

  • AdvancedScenario1A.wsdl is for Scenario 1A.
  • AdvancedScenario1B.wsdl is for Scenario 1B and Scenario 2B.

Refer to the section entitled "Step 3 -- Test the Web service from Rational Developer for System z" in the first article for an example of using the WSDL to test the web service, but use the following endpoints:

  • http://<CICS hostname>:<CICS port>/pureXML/AdvancedScenario1A for Scenario 1A
  • http://<CICS hostname>:<CICS port>/pureXML/AdvancedScenario1B for Scenario 1B and Scenario 2B

Exploring other scenarios

You can store incoming XML messages in hybrid formats, such as XML and relational together. You can also construct outgoing XML messages from hybrid data. In other words, all four of the new scenarios in this article can be mixed and matched. For example, you can show how forms can be used with CICS Web services and DB2 pureXML. See Resources to find out more about the use of Lotus® Forms and pureXML.

In addition, you can use the DB2 pureXML feature along with CICS applications outside the context of CICS Web services. For example, you can construct XML or you can transform XML using SQL/XML. You can also place XML in CICS COMMAREAs or containers.


Conclusion

This article shows how you can store incoming XML data using a CICS Web Service directly in DB2. This capability is available in DB2 9 for z/OS. Using customized CICS handlers, you can parse the XML using SQL to store the XML (the business data) without the SOAP header, either as XML or in relational form. You can also store the data in hybrid format, both as XML and as relational data.

The article also showed how you can publish stored relational data as XML and return it as a response to a CICS Web service. This capability is available in DB2 8 for z/OS. You can publish hybrid data (XML and relational) as XML. This capability is available in DB2 9 for z/OS. The article also explains how you can modify stored XML data directly (this capability is available in DB2 10 for z/OS) and return it as a response to a CICS Web service.

The benefits of DB2 performing the XML manipulations include improved performance (parse-once model) and broad XML manipulation capabilities through XPath and SQL/XML. The creation of a query-able log of inbound messages is a useful bonus.

Samples in a companion zip file, which you can download, configure, and execute, are provided to illustrate and re-create the scenarios described.

Acknowledgments

We'd like to thank Mengchu Cai, Arndt Eade, Ian J Mitchell, and Marcus Paradies for their support and contributions.


Download

DescriptionNameSize
MVSFilesMVSFilesPart2.zip10KB

Resources

Learn

Get products and technologies

  • Build your next development project with IBM trial software, available for download directly from developerWorks.

Discuss

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Information management on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Information Management, XML, SOA and web services
ArticleID=569801
ArticleTitle=Using CICS with DB2 pureXML, Part 2: Perform advanced XML storage and retrieval through CICS Web services
publish-date=11042010