Business Event Processing support for Multiple Objects

TPFUG_Req_Number: SOA13001
ORIGIN DATE: April 18, 2013
REQUIREMENT ABSTRACT (required)

Enhance the Business Event Processing (BEV) capability, released in the recent PUT 9, to support multiple Objects of the same or different types within the ObjectList body of the message. The current implementation supports a single Object structure in the message.

Although sufficient for business event signaling, the current implementation does not support data synchronization of a collection of data structures of different types necessary to describe a file or document.

REQUIREMENT DESCRIPTION (required)
This requirement is not intended to replace the remaining capability requested in the prior SOA11003 requirement, but rather to augment the current Business Event Processing Framework release.

Enhance the current TPF Data Model Descriptor (TDMD) conventions and tooling to support multiple tns:Object types within a tns:ObjectList.

The TDMD must provide a mechanism when parsing and transforming, to associate a TPFDF LREC or similar structure type to the appropriate tns:Object within the tns:ObjectList of its TDMD (e.g. associate the Object Name or aName for the C Header or MACRO DSECT file to the LREC Key and sub-file in order that a LREC may be associated to a specific Object in the TPF Data Model Descriptor).

Enhance the current Business Event (BEV) processing framework release to convert a set of one or more TPFDF LRECs or similar structures, from contiguous memory or a TPFDF sub-file, into the body of an XML message.
The mechanism must enable the TPFDF LREC or similar structures to be traversed, the structure type identified, the structure associated with its tns:Object from TPF Data Model Descriptor (TDMD), and transformed into its XML equivalent structure (XMLDF).

The resulting XML body may be an XML document or a series of XML fragments.

In later releases, the developer will be able to use the z/TPF "Toolkit" (Eclipse Development facility) to define the TPF Data Model Descriptors.

In later releases, the developer will be able to use the z/TPF Tool Kit to generate the appropriate WSDL and XML Schema from the TPF Data Model Descriptor.

CRITICAL SUCCESS FACTORS (optional)
• TPF Data Modeling Descriptor can support multiple Object types within the ObjectList collection description.
• The multi-Object descriptor can be deployed in a z/TPF system.
• The Business Event Processing framework can process multiple Objects of multiple instances and multiple types within an ObjectList.
• The Business Event Processing framework can will be able to traverse the fixed or LREC like, linked-list, variable length structures, locate and identify the Object type dynamically, transform the event body structure as described by its data model descriptor into its XML equivalent.
• Send a copy of this event to each consumer configured via the Business Event Dispatch Adapter Specification.

ALTERNATIVE SOLUTIONS (optional)

SOLUTION CONSIDERATIONS (required)
Those z/TPF clients that have invested heavily in Event Driven Architectures are using their proprietary infrastructures primarily to synchronize operational data to Operational Data Stores, Data Warehouses, and Enterprise Service Bus' for transformation, load, and publishing. Though Business Event signaling consumers are supported in this release, the value and reuse to early adopters is in its use for data synchronization.
Though the initial release of BEV in PUT9 provides a good indication of IBM's solution approach and transformation capabilities, it falls short of a mechanism to support data synchronization of complex data hierarchies whether flattened or not. The notion of variable number of structures of different types requires a mechanism of determining the end of one structure and the identification of its type. This kind of mechanism is readily available in TPFDF source structures but must be established by convention in others. The goal of the initial SOA11003 requirement was to support the low hanging fruit of TPFDF structures and evolve from there with experience.