When business events were first introduced for z/TPF on PUT 9, business event support allowed you to easily define signal events using event specifications (XML files). You also created dispatch adapters (more XML files) to define how to format signal events and transmit them to other platforms. After the specifications were defined and deployed on z/TPF, signal events were generated by inserting a call to the tpf_bev_signal() function in your application. By doing this, you could easily signal other systems that some event occurred on the z/TPF system. For example, your applications could send signal events for spending limits on credit cards or low availability on a flight, train, or hotel rooms.
With APARs PJ42280 and PI18980, business events supports data events for z/TPFDF files. Similar to signal events, you define and deploy event specifications and dispatch adapters for data events. Instead of adding a tpf_bev_signal() function to your application, you update the DBDEF macros to enable data events for the z/TPFDF files you are interested in. After data events are fully enabled, the z/TPF system will automatically generate data events whenever the enabled z/TPFDF files are created, updated, or deleted by standard z/TPFDF APIs. By enabling data events, your z/TPF system can automatically send PNRs, inventory, credit card transactions, or other z/TPFDF subfiles to data warehouses, analytics engines, data caches, or other database servers for use by other systems in your enterprise - all without changing applications or putting hooks in your database update routines!
In general, a data event for z/TPFDF represents the changes from when the z/TPFDF subfile is opened to when it is closed. Depending on what kind of z/TPFDF files are enabling for data events, you can choose to collect only changed LRECs or choose to collect the entire subfile for each data event. For example, if the data event is for a credit card transaction database, you may want to collect only the updated LRECs representing the current transaction. When the data event is for a passenger record, the full subfile may be better to provide the full context of any update. You can also filter which LRECs are collected by LREC ID. This may be useful if you want to ignore certain types of LRECs for data events, like change history. These options are part of the event specification for each data event, so each data event can be configured differently based on the nature of z/TPFDF file being collected.
Data events use the event message format to describe the event data and supporting context. Each event message contains the event header (event name, timestamp, etc.), optional context areas, and the event data (z/TPFDF LRECs and subfile information), all of which are described using standard Data Format Description Language (DFDL) syntax in DFDL schema files. By using DFDL schemas and a standard syntax, you can use these schema files to define the event message format to z/TPF business event processing, use those schemas to generate XML or JSON documents on z/TPF, and use those same schema files to parse a binary event message using a standard DFDL parser on another platform.
Signal events have been extended to use the event message format as well. With the original signal event support on PUT 9, signal events were defined using the TPF Data Model (TDM). TDM worked well for simple data types and structures, but did not support nested objects or or complex data structures with varying data definitions. For signal events, each event message contains the same sections as a data event: the event header, optional context areas, and the event data. The DFDL schemas used by the event message format support nested objects and complex data types of varying lengths and definitions, allowing you greater flexibility when defining your signal event data.
By fully supporting data events for z/TPFDF and by describing event messages for both signal and data events through standard DFDL schemas, event message business events are the next step in unlocking the value of your z/TPF data.