Introduction

Once the consistency has been reviewed, the next phase is to define the configuration allowing to build 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. The CAST Transaction Configuration Center (TCC) is the tool that will allow you to perform all the tasks related to transaction configuration:

Click to enlarge:

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 CAST AIP and extensions

CAST AIP ≥ 8.3.x and some CAST AIP 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 in each Free Definition rules node under the Application node:

Click to enlarge:

Or you can view them in the Application > Transaction Configuration node:

The number of objects that match these predefined configuration rules is listed in the Application > Transaction Configuration > sub node > Free Definition node:

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 in the Application > Transaction Configuration > sub node > Free Definition node:

or in the Application > Transaction Configuration node:

Configure Transaction Entry Points

The first action to do is to run the CAST Transaction Configuration Center and access the application. Then go to the Entry points node in the Templates node.

This step aims to register correctly 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.

Searching for objects using their type

The CAST Transaction Configuration Center is initialized with a set of predefined object types under the node By type:

You should first review this list to avoid creating duplicate rules. You can also add rules to select new objects as Transaction Entry Points. For example, for the Mainframe technology, JCL Jobs and CICS Transactions are considered as Transaction Entry Points by default but if the application uses BMS map, then you can add a rule to select this type of objects as a Transaction Entry Point.

If you have to deal with a subset of types such as a certain category of jobs or programs, then you should use Free Definition rules (instead of adding a new type) in conjunction with exclusions to clean up selected objects.

Searching for objects by using their inheritance

If the technology does not allow you to select objects by their type, then you can opt for another approach. As an example, an implementation based on Java Swing can be handled by selecting the super class as the root of the Transaction Entry Point. Defining By inheritance rules for JFrame and JPanel classes will automatically select screens existing in the application.

CAST recommends using Free Definition rules instead of By Inheritance rules if the selection of the parent class must be done by name and not full name. You will obtain more accurate results using Free Definition rules:

Searching for objects with Free Definition rules

This type of rule is very powerful and generally allows you to address most situations you may be confronted with:

Searching for objects by their name

Selecting Transaction Entry Points using their name should be the final option since this is a declarative approach. It forces you to keep a specific task as part of the on-going process to regularly verify with the SME whether you need to add a new Transaction Entry Point to your set of rules:

Configure Data Entities

The first action to do is to run the CAST Transaction Configuration Center and access the application. Then go to the Data Entities node in the Templates node:

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.

Searching for objects using their type

The CAST Transaction Configuration Center is initialized with a set of predefined object types. You should review this list to avoid creating duplicate rules:

You can add rules to select new objects as Data Entities. For example, for the Mainframe technology, CICS Dataset, IMS DBD, SQL Tables and other COBOL File Links objects are considered as Data Entites by default. These objects are potential members of a persistence layer but, part or all the objects for some types can be excluded in a further configuration if the architecture requires this exclusion. As an example, COBOL File Link objects will be viewed as temporary files if the data is persistent in a database. In this case, we will keep only the COBOL File Link objects corresponding to reports, or pure output or input. 

Depending on the application's architecture, you can add some specific elements as part of the persistence layer. In the below example we added the GSAM files since the application is storing information in an IMS database and in GSAM files:

Click to enlarge:

Searching for objects using their name

Even if this type of rule can be used, it is quite rare to search for Data Entities using their name. In addition to selecting objects by their name, 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):

Searching for objects by using their inheritance

Even if this type of rule can be used, it is not generally recommended to search for Data Entities using inheritance.

Searching for objects with Free Definition rules

Even if this type of rule can be used, it is not generally recommended to search for Data Entities using Free Definition rules.

Configure Transaction End Points

The next step of the interface review and configuration in CAST AIP will be to continue to use the CAST Transaction Calibration Center 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 have to on-board. 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:

Searching for objects using their type

This is a simple selection that can be done to identify unresolved objects or some objects that have been generated by a Universal Analyzer configuration:

Searching for object using their name

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:

Searching for objects using their inheritance

CAST recommends using Free Definition rules instead of By Inheritance rules if the selection of the parent class must be done by name and not full name. You will obtain more accurate results using Free Definition rules:

Searching for objects using 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:

Select 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
WHERE  EXT.IDOBJ = OBJ.OBJECT_ID
     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
WHERE  EXT.IDOBJ = OBJ.OBJECT_ID
     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
WHERE  EXT.IDOBJ = OBJ.OBJECT_ID
     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 
ORDER BY 2 DESC;

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
   </property>
  </selection-criteria>
</set>
' 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 familiar By naming, By inheritance, By type, and Free Definition rules:

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:

1. Check the list of technologies and frameworks used by the application
2. For each technology for which there is a ".tccsetup" export file available,
   1. Perform an Update configuration in the Templates node of the CAST Transaction Configuration Center
3. Export (Export setup) your generic configuration from the Templates node into a ".tccsetup" file
4. Right-click the application Setup node, and Import the ".tccsetup" file
5. Tune the transaction configuration based on the application specific technologies or frameworks that are not yet part of this predefined library
6. Once done, Export your configuration and share it with your CAST contact (who will provide the CAST Product Management Team with feedback) in order to help improve the CAST Transaction Configuration Center configuration library

Check the list of technologies and frameworks used in the Application

The first simple action you can do if you do not know the technologies used by your application, is to open the CAST Transaction Configuration Center and select the Application as shown below. Use the tables at the bottom of the right hand panel to get a list of all the object types that have been identified in the application:

Click to enlarge:

The above tables allow you to understand the technologies used by your application. If you want to import the configuration for additional frameworks and API, then you should use CAST Enlighten (as shown below) or execute an SQL query to list all the external and internal classes, package per package:

Click to enlarge:

Update the Templates section with a .tccsetup file

The first step is to select the Templates node in the CAST Transaction Configuration. It is important to ensure that the template is empty (apart from the default items in the Entry points > By Type and Data Entities > Ignored Tables nodes) in order to not propagate previous configurations. If you want to start from a clean environment, you must export a clean configuration from another environment and import it into the Templates node before continuing:

Click to enlarge:

Next, right click the Templates node and select Upload configuration in the popup menu to enrich the existing configuration. The below actions can be done multiple times if you have several technologies in your application and need to upload multiple custom tccsetup files:

In the following example, we willl import a custom configuration for Mainframe:

When a configuration has been uploaded, you can see new rules for Data Entities, Entry Points, End Points, and Excluded Items appearing on views associated to the Templates node. The upload action prevents duplicates: a configuration cannot be imported/uploaded twice:

The following screen shot displays an example of a custom configuration that has been imported/uploaded:

Export your final default configuration

Once your configuration is ready to be used with Applications, right click the Templates node and select Export configuration:

Save your configuration in a file:

Import your TCC configuration file into the Setup node of your application

Once the configuration has been saved, select your Application and expand it to find the Transaction Configuration node. Right click this and select Import Configuration:

 Import the configuration file in to your Application: