CAST Console - How to configure Transactions?

This step builds the transactions implemented in the application. This is done by creating specific rules for Transaction Entry Points and End Points as well as for the identification of Data Entities. There are two methods of doing this:

Console: Transaction UI

Available in Console after an initial Application analysis has been completed. Documentation is available in Application - Transactions:



Several concepts and their associated steps are used during the transaction configuration phase:

  • Configure Transaction Entry Points: this step describes defining rules to select any kind of interface with end-users or other applications.
  • Configure Data Entities: this step describes defining rules to select any kind of data persistence layers within the application
  • Configure Transaction End Points: this step describes defining rules to select any kind of data persistence layer which are not part of the application (they belong to other applications) and are not delivered with the source code. As such, they should be considered as Transaction End Points.
  • Configure Excluded items: defining rules to exclude specific elements (Data Entities or Transaction Entry Points) from the application boundary.

In each step you can define four types of rules, depending on the objects you need to address:

  • By naming: search for objects using their name
  • By inheritance: search for classes and interfaces using the inheritance links they can have
  • By type: search objects through their type
  • Free Definition: define complex rules to search for objects, based on names, types, links, and properties



Predefined configuration rules delivered with AIP Core and extensions

Note that the predefined configuration rules discussed below are also available through the SME KIT - Transaction Configuration Kit - if you are using AIP Core ≥ 8.3.x there is no need to download and install this extension as the rules are already provided out-of-the box.

AIP Core ≥ 8.3.x and some extensions are delivered with a set of predefined configuration rules that are designed to meet the majority of simple use cases. You can see these predefined rules as follows:


Click to enlarge



The number of objects that match these predefined configuration rules is also displayed:



CAST recommends that you check whether the predefined rules and the objects that have been matched are appropriate and to avoid creating duplicate rules. If you find that the rules are not appropriate, you can deactivate the predefined rule:



How to Configure Transaction Entry Points

The first action is to find the Entry points rules. This step aims to register the default interface automatically used by the system to identify transaction entry points. The result of this operation is a list of transactions that will be reviewed by the SME to ensure you do not miss any interfaces.



Adding new Transaction Entry Points via Free Definition rules

This type of rule is very powerful and generally allows you to address most situations you may be confronted with. In Console, this method of searching for specific objects to define as Transaction Entry Points is the only method available:





Configure Data Entities

Data Entities should be the type of elements to consider as part of the persistence layer. These elements should contain the data such as the tables or flat files. Any temporary files or objects should NOT be targeted in this step.




Predefined data entities

Console and the CAST Transaction Configuration Center are initialized with a set of predefined object types and rules in the Built-in types and Free Definition nodes. You should review this list to avoid creating duplicate rules:



Adding new data entity rules via Free Definition rules

You can add rules to select new objects as Data Entities. When using Console, Free Definition is the only method available:


Tables to ignore

You should also review the list of patterns predefined in the "built-in" section. These rules will automatically exclude elements from the calibration. These Data Entities will not be displayed in any list (kept, ignored, or deleted Data Entities):




Configure Transaction End Points

The next step of the interface review and configuration is to ensure you have the right definition of Transaction End Points. In this part we intend to review the potential interfaces of the application you are on-boarding. If the application is using specific APIs or web services exposed by another application, then you should configure those end points.

The approach will be to review the interface with external APIs in order to pick up all of those that interact with a persistence layer such as a file, an outputStream, inputStream, MQueue, Mail, FileStream, writer, reader... All these APIs should be configured as a Transaction End Point with a contribution set to 1. Other APIs that do not represent a persistence layer should be configured with a contribution set to 0.

A set of predefined Transaction End Point rules are available out of the box:




Adding new Transaction end points rules via Free Definition rules

Free Definition rules are an extremely powerful method of configuring Transaction End Points. Using this approach you should consider the population you are targeting in other applications (ex: web services, message Queues, API, ...). The Transaction End Points are the elements that call this population:




This type of rule is generally used with legacy technologies such as Mainframe to select specific programs that are used to implement functionalities outside the application. In this case these objects are normally in the list of unresolved programs and it is easy to select those that are required:


Add new Transaction End Points from external APIs

Some external classes can be considered as APIs provided by other applications. In the current application, objects calling these APIs can be considered as Transaction End Points. Moreover, those that call APIs managing data flow contribute to transaction weight. Creating rules to handle these objects can be done in several steps:

  • Search for external classes
  • Identify those that process data flow
  • Generate the list of objects to be added to the Free Definition rule selection criteria
  • Create the Free Definition rules

Search for external classes

External JEE APIs used by the application

The following SQL query collects Java methods used as APIs:

SET Search_path=<Prefix>_local;
SELECT DISTINCT OBJ.object_fullname
FROM cdt_objects OBJ, OBJPRO EXT
     AND  OBJ.object_language_name = 'Java'
     AND OBJ.object_type_str = 'Java Method'
     AND EXT.Prop = 1
     AND OBJ.object_name NOT LIKE '_jspService'
ORDER BY object_fullname ASC;

Search for external .NET APIs used by the application

The following SQL query collects .NET classes used as APIs:

SET Search_path=<Prefix>_local;

SELECT DISTINCT OBJ.object_fullname
FROM cdt_objects OBJ, OBJPRO EXT
     AND  OBJ.object_language_name = '.NET'
     AND OBJ.object_type_str like '%.NET Class'
     AND EXT.Prop = 1
ORDER BY object_fullname ASC;

Identify external APIs that process data flow

Review the objects identified in the previous step and identify those that process data. They can then be added to a specific Free Definition rule for Transaction End Points defined with a contribution set to 1. Add the name of the objects that have been identified in the following SQL query selection criteria:

SET Search_path=<Prefix>_local;

SELECT DISTINCT '<value>'||OBJ.object_fullname||'</value>' as pattern, count (1)

FROM cdt_objects OBJ, OBJPRO EXT, ctv_links CLI
     AND  OBJ.object_language_name = '.NET'
     AND OBJ.object_type_str like '%.NET Class'
     AND EXT.Prop = 1
     AND CLI.called_id = OBJ.OBJECT_ID
     --AND OBJ.object_fullname like '%Stream%'
     and object_fullname not in ('<Replace With The Content Of Your Free Definition With A Contribution at 1>')
     GROUP BY 1 having count(1)< 10000 

The result produced by the execution of the query should look like this:

You can now create a new dedicated Free Definition rule to select Transaction End Points corresponding to external APIs. You could call it "Exposed Program" for instance. Once it has been created, replace the regular expression implemented in the rule by using the following SQL query (matched to your environment) in which you insert the list of objects you obtained previously:

set search_path=<Prefix>_mngt;
update cal_objsetdef set setdefinition = '<set>
  <selection-criteria subobjects="no" externalobjects="yes">
   <property name = "fullname" operator = "like" >
    <value>...</value> -- result of the previous query
' where setname = '<Replace With The Name Of Your Free Definition>';

The result is visible in the CAST Transaction Configuration Center, in the definition of the rule:

You can now create a Free Definition rule to select the Transaction End Points that call the external API processing data:

Configure Excluded Items

If you need to specifically exclude certain items from the Application boundary, you can do so by using the Excluded Items section:





How to reuse and merge CAST Transaction Configuration Center configurations

Each application is specific in terms of technologies and frameworks. A significant part of the effort in configuring transactions is to cover common and specific technologies. A CAST Transaction Configuration Center configuration library will help you to configure the common part, meaning that you can focus on the specific part. In order to build your CAST Transaction Configuration Center default configuration you should use the following instructions:


Use the import/export options to export rules to file to store outside of Console. Then use the import option when you need to re-use the same rule:



Transaction and Function Point management - Transaction configuration


Have more questions? Submit a request


Powered by Zendesk