Dynamic Transactions as View of Other Transactions

In GeneXus 15, there are some interesting improvements to data modeling and to the power of transactions. In particular, we can define a transaction which has an associated Data Provider, which allows for some basic functions and specializations of said transaction, such as Dynamic Transactions.

The background impact of this improvement is that development becomes more oriented towards the Transaction/Attribute paradigm, which makes it much easier for a GeneXus Developer, since this is a paradigm which he knows and controls.

An example application of those “basic functions”: when one defines that a transaction will have an associated Data Provider (Data Provider property in Transactions) one can do interesting things, such as populate the transaction’s data at the moment of creation/reorganization from that Data Provider (among other things). This way, “loading procedures” are not necessary and one does not need to worry about their execution.

A notable example of specialization is dynamic transactions, where a transaction can serve as a "view" of others (resulting in an SQL VIEW) by leveraging these properties and using a Data Provider to "populate" it. For instance, one could create a single transaction as a UNION of different structures, managing it as a unified entity.

The applications of these definitions are endless. The following small example demonstrates consolidating information from different transactions into one, allowing its use as a whole. In this context, "use" means being able to apply For Each commands, Data Providers (DPs), and other operations on these dynamic transactions, even employing them as foreign keys in other transactions.

The Example

A GeneXus application called "Sales" has Products, Services, and Purchase Orders (PO), where the PO transaction contains two sublevels: Products Sold and Services Sold:

This example is simplified. In reality, Products and Services typically have distinct attributes: a Product may have color, measurements, etc., while a Service may have duration, cost, etc.

A Dynamic Transaction (ProductAndService) can be defined with an associated Data Provider to "load" data from both Product and Service structures (illustrated by the red arrows). Essentially, this acts as a VIEW, implementing the UNION of the two transactions. "Load" is quoted because no redundant data is created — the view consolidates the information dynamically.

Once defined, the PO transaction can include a single sublevel that references ProductAndService keys as foreign keys.

Similarly, a Web Panel can directly access this "table" by referencing its attributes, displaying the transaction as a service. Additionally, Insert, Update, and Delete methods can be implemented on the dynamic transaction, as detailed in Dynamic Transactions that update data.

Implementation

This example (the Knowledge Base) is available for download here for those interested in exploring object definitions, properties, and other specifics.

The most relevant part

The ProductAndService transaction has an associated Data Provider and is used to retrieve data:

The Data Provider created by default was modified to define where the data is obtained from:

ProductAndServiceCollection{
    ProductAndService
    {
        ProductAndServiceType = !"P"
        ProductAndServiceId = ProductId
        ProductAndServiceName = ProductName
    }
    ProductAndService
    {
        ProductAndServiceType = !"S"
        ProductAndServiceId = ServiceId
        ProductAndServiceName = ServiceName
    }
}

Note: In the dynamic transaction "ProductAndService," since a product key might overlap with a service key, a "Type" attribute (P or S) was added as part of the primary key.

Additionally, in this example, the "Data Provider to initialize data in a transaction" concept is also applied to the Product and Service transactions.