Meet-in-middle development

This group of topics describes issues involved in meet-in-middle development.

Support for the IMS Callout (ICAL) call

This topic describes the support of the IMS Callout (ICAL) call by the XML converters.

Scenario

When you generate files for a Web service requester for the IMS runtime using the meet-in-middle scenario and compiled conversion, you can select either the synchronous or the asynchronous type of callout message.

Asynchronous callout means that the IMS application invokes the Web service requester by issuing an IMS Insert (ISRT) call, which places the outgoing request message into the IMS message queue. Likewise when the Web service requester receives the response to the request, it places the incoming response message into the IMS message queue for the IMS application to retrieve.

Synchronous callout means that the IMS application invokes the Web service requester by issuing an IMS Callout (ICAL) call, which synchronously invokes the Web service requester with the outgoing request message. When the Web service requester receives the response to the request, the incoming response message is returned to the IMS application through the return from the ICAL call.

For the IMS application it is usually much more convenient to issue a synchronous call.

To select asynchronous or synchronous processing:

In the graphical user interface, select the appropriate value in the Callout message type list box on the IMS Enterprise Suite SOAP Gateway Service Requester page of the meet-in-middle wizard.
In the batch processor, select the appropriate value in the GEN_IMS_MESSAGE_TYPE attribute in the CodegenProperty element (see CodegenProperty).

Support for IMS Callout (ICAL)

Compiled XML Conversion artifacts generated by prior versions of Developer for z/OS® are compatible with the ICAL call only if the mapped 01 level language structures begin with LL and ZZ fields.

Because the ICAL call bypasses IMS message queues, the call requires that the request and response data for the remote web service are entirely contained in at most two 01 level language structures, one for the request and one for the response. In addition, language structures do not need to begin with LL and ZZ since these fields are used only with asynchronous messaging; if these fields are defined in an 01 level language structure used with ICAL, the fields are treated as data.

Support for the nillable attribute

Edit online

This topic describes the support for the nillable attribute in the COBOL Compiled XML Conversion process.

The nillable attribute can be defined on an xsd:element within an XML schema. It specifies that the xsi:nil attribute is valid for the element. If an XML schema has defined the nillable attribute as true, it is mapped as a required attribute and is included in the document, however, its values are nullified. Depending on the circumstances, the XML conversion process behaves differently when nillable elements are mapped.

The XML2LS (inbound) converter will move all LOW-VALUES to a COBOL field if the following conditions are met:

The XSD element that is mapped to the COBOL field has nillable="true".
The XSD element is mapped to a COBOL field of type PIC X, G, or N.
The XML element specifies xsi:nil="true" and has a content length of 0 (no character content) at execution time.

The LS2XML (outbound) converter will generate the xsi:nil="true" attribute(*2) on an XML element if the following conditions are met:

The XSD element to which the COBOL field is mapped specifies nillable="true".
The COBOL field to which the XSD element is mapped is of type PIC X, G, or N.
The COBOL field contains all LOW-VALUES at execution time.

In Figure 1, when the COPY and XSD files are imported and the COBOL field ELE-1 is mapped to the XSD item ele_1, the following results will be achieved:

The XML2LS converter will move all LOW-VALUES to ELE-1 if the XML content does not contain character content like <el1_1 attr_1="01020" xsi:nil="true"/> at execution time.
The LS2XML converter will generate <el1_1 attr_1="01020" xsi:nil="true"/> if ELE-1 contains all LOW-VALUES at execution time.

Figure 1. xsd:nillable Example

COPY:
01 STRUCT-1.
	05 ATTR-1 PIC X(5).
	05 ELE-1 PIC X(10).

XSD:
<?xml version="1.0" encoding="UTF-8" ?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:p1="http://www.example.com"
targetNamespace="http://www.example.com"
elementFormDefault="unqualified"
attributeFormDefault="unqualified">

	<xs:element name="ele1_detail">
		<xs:complexType>
			<xs:sequence>
				<xs:element name="ele_1" type="p1:ele_1" nillable="true"/>
			</xs:sequence>
		</xs:complexType>
	</xs:element>

	<xs:complexType name="ele_1">
		<xs:simpleContent>
			<xs:extension base="xs:string">
				<xs:attribute name="attr-1">
					<xs:simpleType>
						<xs:restriction base="xs:string">
						</xs:restriction>
					</xs:simpleType>
				</xs:attribute>
			</xs:extension>
		</xs:simpleContent>
	</xs:complexType>

</xs:schema>