Page tree
Skip to end of metadata
Go to start of metadata
On this page

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.

 

Some views combine lots of information so it is important to be disciplined to achieve the actions correctly.

Preamble

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

  • Transaction Entry Points: this step describes defining rules to select any kind of interface with end-users or other applications.
  • Data Function definition: this step describes defining rules to select any kind of data persistence layers within the application
  • 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.
  • Exclusion items: this step describes 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 by using their name
  • By inheritance: search for classes and interfaces by 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

Configure Transaction Entry Points

The first action to do is to run TCC and access the application. Then go to the "Transaction entry points" view in the Templates node.

This step aims to register correctly the default interface automatically used by the system to identify transaction starting 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 interface.

Searching for objects through their type

TCC 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 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 By Inheritance rules if the selection of the parent class must be done by name and not full name. You will have more accurate result using Free Definition:

 

Searching for objects with Free Definition rules

This type of rule is very powerful and generally allows you to address most of cases:

 

Searching for objects by their name

Selecting Transaction Entry Points by 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 Functions

The first action to do is to run TCC and access the application. Then go to the "Data functions" view in the Templates node.


The Data Functions should be the type of elements to consider as part of the persistence layer. Those elements should contain the data such as the tables or flat files. All the temporary files or objects should not be targeted in this section. 

Searching for objects through their type

TCC 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 Functions. For example, for the Mainframe technology, CICS Dataset, IMS DBD, SQL Tables and other COBOL File Links objects are considered as Data Functions 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, the 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. 

Searching for objects by their name

Even if this type of rule can be used it is quite rare to search for Data Functions 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 quite rare to search for Data Functions by using their inheritance links.

Searching for objects with Free Definition rules

Even if this type of rule can be used it is quite rare to search for Data Functions by 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 in the 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 API or web services exposed by another application, then you should configure those end points.

The approach will be to review the interface with external API 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 API should be configured as a Transaction End Point with a contribution set to 1. The other API that do not represent a persistence layer should be configured with a contribution set to 0.

 

Searching for objects by 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 by 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 by using their inheritance

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

Searching for objects by using Free Definition rules

Free Definition rules are very useful to select Transaction End Points. In 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 API

Some of external classes can be considered as API provided by other applications. In the current application, objects calling these API can be considered as Transaction End Points. Moreover, those that call API 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 JEE API used by the application

The following SQL query collects Java methods used as API:

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 API used by the application (CAST AIP v7)

The following SQL query collects .NET classes used as API. It is only applicable for CAST AIP 7.x.

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 = '.NET class'
     AND EXT.Prop = 1
ORDER BY object_fullname ASC;

Search for external .Net API used by the application (CAST AIP v8)

The following SQL query collects .NET classes used as API. It is only applicable for CAST AIP 8.x.

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 API that process data flow

Review the objects identified in the previous step and identify those that process data. They will 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 in TCC to select Transaction End Points corresponding to external API. You can called it "Exposed Program" for instance. Once it has been created, replace the regular expression implemented in the rule by using the following SQL query 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 TCC, 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:

How to reuse and merge TCC 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 TCC configuration library will help you to configure the common part, meaning that you can focus on the specific part. In order to build your TCC default configuration you should follow 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,
    1. Perform an Update configuration in the Templates node of TCC
  3. Export (Export setup) your generic configuration from the Templates node into a TCC file
  4. Right-click the application Setup node, and Import the above TCC 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 TCC configuration library

Check the list of used technologies and frameworks

The first simple action you can do if you do not know the technologies used by your application, is to open TCC and select the application as showed in the below screen shot (the step 1). Then, click on Load object types used by this application as well as the View Technologies button in order to get a list of all the object types that have been identified in the application:

 

The result of Load object types used by this application is displayed in a table that contains the list of all object types:

 

The above table allows 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 (illustrated in the step 4 of the below screen shot) or execute a SQL query to list all the external and internal classes, package per package.

 

Update the Templates section

The first step is to select the Templates node in TCC. It is important to be sure the template is empty in order to not propagate previous configurations from your sandbox environment. 

The second step is to right-click the Templates node to access the popup menu which will allow you to import and export the setup, and to upload a configuration:

The third step is to select the "Upload configuration" item in the popup menu to enrich the existing configuration. If you want to start from a clean environment, you must export the TCC configuration from another environment and import this one in the Templates node before operating the upload action. The below actions 3 to 6 can be done multiple times if you have several technologies in your application. 

Then select the "Upload configuration" action and select the technology for which you want to import the configuration. In the following example, we import the TCC configuration for the COBOL technology:

When a configuration has been uploaded, you can see new rules for Data Functions, Transaction Entry Points, Transaction 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 configuration (here for the COBOL technology) that has been imported/uploaded in TCC:

Export your final default configuration

Once your configuration is ready to be used with applications, select the Templates node:

... right-click to make the associated popup menu appear:

 

and select the "Export setup" item:

Save your TCC 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 see the Setup node:

Right-click the Setup node and select the Import item in the popup menu that appears. Keep in mind that this operation will replace the current configuration with a new one. If you have to merge a specific configuration with the one you want to import, then you must perform this operation in the Templates node. To do that, export the configuration defined for your application and upload it into the Templates node. You can now export the new configuration from the Templates node and import it into your application.

Import the configuration file in your application setup:

 

  • No labels