TxExpo help - Transactions

 

Transactions are what TransactionExpo is all about. A transaction in TransactionExpo is a set of events and their interconnections, reflecting a process in the real world. It is represented internally as a directed graph (or more accurately, a directed tree): the different events are the nodes, and the edges between the nodes are directed, that is each edge has a source node and a target node. A transaction has at least one starting node (corresponding to the event that initializes the transaction), and each node in the transaction is connected to a set of nodes, corresponding to different events that may take place after the event represented by that node. A sub set of the transaction's
nodes is defined as end nodes and corresponds to closing events that mark the ending of the transaction.
One familiar example of a transaction is that of withdrawing money from an ATM, as shown in the figure bellow:
 

The transaction begins by inserting the debit card, after which the person withdrawing the money (the user) is requested to enter his PIN code. The PIN is then checked, and in case of approval the user is then prompted to insert the withdrawal amount. A further check is done at this stage that either confirms or denies the withdrawal request.
In case of approval, the debit card is returned, the user withdraws the cash and the transaction ends. The flow of the transaction as described here is called the main scenario.
There are also alternative scenarios: the PIN code entered can be incorrect, and the user will be prompted to enter the PIN code once again; or, after PIN code approval, the
user may also not be able to withdraw the amount he requested (not enough money in his account). In that case he might be prompted to enter another amount, or as in the figure depicted above, the transaction can end here with no money withdrawal.

Tracking manually transaction among myriads of events is very tedious, often impossible. This is where TransactionExpo comes into play: After a transaction was defined, TransactionExpo uses its correlation engine to match data found in your data sources into events and transactions. Each time the correlation engine is being executed a
result set
is created containing all the transactions found in your data sources (and obeying constraints such as time frames). The
transactions contained in the result set are called runtime transactions. They are saved into TransactionExpo's database and can be further analyzed and displayed.
The transaction definitions these runtime transactions are based upon is called a  transaction paradigms. We call also the transaction paradigm of a runtime transaction
its type.

 


Defining a Transaction
  1. From the 'Administration' menu, select 'Transactions' to enter the transaction paradigms page.

  2. Click on the 'Add new' link to create a new transaction or click on the 'edit' link of an existing transaction to edit it.

  3. The transaction administration screen is divided to two tabs: Visual View and Preferences.

  4. The Visual View tab is divided to two parts: the top shows a graph representation of the topology of the transaction and the bottom shows the list of nodes that exist in the graph. In order to create the transaction definition, you need to define the topology of the transaction. The topology of a transaction is the set of nodes and edges that define its structure. The Visual View tab allows you to add nodes to the topology. The nodes can be either routine nodes or group nodes (which, in turn, can contain other routine and group nodes). After you add a node to the topology, a row of data related to this node is added to the nodes list in the bottom of the screen.
    The topology graph representation is an interactive control. Placing the mouse over a routine node in the graph you will display a short summary of its preferences. Placing the mouse over a group node will display its content. Clicking the arrow icon that appears when the mouse is over a node will open a menu of the operations that could be performed on the node or on it's outgoing connectors. Clicking a node will open its data definition in the nodes list. Double clicking the group icon will zoom into the group.


    A routine node has the following data available for configuration:
    General:
    In this tab you can set the name of the routine and optionally add a description.
    Next comes the definition of the event this routine corresponds to. Events are represented in TransactionExpo as data sources, with of without filters, and are
    defined in XpoLog as logs. These events are the occurrence of certain information units in your data. They can be, for instance, entries in a log file baring some
    unique information or records from a database table. For example, the log file logging all ATM events may include the following line:
    '[2006-02-27 08:00:26,968] [Thread-3] [INFO] [atm.consoritum.Validator] [atm.consoritum.Validator.checkPIN(Validator.java:117)] [Code:128]
    PIN code accepted'
    indicating that a the right PIN code has been entered. In order to use this event in your transaction, you first have to define a log based on your ATM log file. Once
    the ATM log has been defined, you can define filters that restrict the data retrieved from that log according to some criteria. Using the above example again, a filter
    retrieving only log entries having code 128 may be used to define the event 'PIN code accepted'. To learn more on how to define logs and filters, see logs and filters.
    Now that we know what events are, we can move ahead to the definition of data sources. Click the three dots (...) icon to open the
    data source (log) selection window. The data source selection window displays a tree of all the folders and logs defined in your XpoLog center, including remote
    XpoLog nodes
    and their folders and logs. Using the expand link ('+') open the folder that contains your data source (log) and select it. You can also select a filter from the list of filters of the log you selected. To complete your selection, click the 'ok' link at the bottom of the page. The selected data source and filter will be displayed in the tab.
    Now that the routine's data source has been defined you can move forward to define further characteristics of the routine:
    Select the 'open' option if the routine is a starting node representing an event which initiates the transaction. There may be multiple starting routines.
    Select the 'single' option if the routine can appear only once in a transaction. Using the ATM example again, the routine representing the 'Insert PIN' event should
    be defined as non-single since a failure in entering the right PIN code results in a further prompt for entering the right PIN.
    The 'optional' option indicates whether this routine is optional or mandatory. In case a transaction is created (during an execution of the project containing it) in
    which a routine defined as mandatory is missing then the transaction will be adequately marked (erroneous topology status)
    Select the 'end' option if the routine is an end routine representing an event which marks the end of the transaction. There may be multiple end routines, and the
    transactions created during a result set execution may end with any of these routines.

    Functions:
    In this tab you see a list of all incoming functions of the routine. A function can be seen as a logical edge, that is an edge that does not 'physically', or rather topologically, connects two nodes but rather defines a relation among any two nodes. Thus the routines and the logical edges define a logical graph, on top of the topological graph described by the transaction's nodes and topological edges.
    In order to define a logical edge, select first the function operator. Current, only the 'equals' operator is available.
    Next, select from the 'Source Schema' combo box the routine that will be the source routine of the logical edge; the target edge is always the current routine being
    defined. After the source routine has been selected, the fields of that routine's data source will be automatically displayed in the list below. Next to it is the list of fields of the current routine's data source. In each list, select the field that should participate in the function and click on the 'add' link to apply the function for these two fields (operands). For instance, if the source routine's data source (event) has a field called 'sessId' that should have the same value as the field 'sessionId' in the current routine's data source, select these two fields add click 'add'. If the (equals-) function that connects two routines is defined by more than one pair of operands, repeat the
    fields' selection operation with another pair of operands. Use the 'remove' link to remove pairs of operands from the function. Click the 'Add Function' link to add the function to the functions list.

    Connectors:
    In this tab you see a list of the outgoing edges of the routine. You can add new edges by selecting the type of new node you wish to create and clicking the 'New Connector' link. You can remove edges by clicking the icon at the end of the row of each edge.
    When you click an edge from the list you can set the name of the edge and optionally add a description. In the 'Life cycle' field you should enter the maximal time span that could elapse between arrival of the edge's source node and the arrival of its target node. It defines the time flow constraints between two nodes. If an edge of a runtime transaction does not obey to this time flow constraint (the time span between two events was too long) it will be adequately marked, but the time status of the transaction as a whole won't be necessarily affected.

    Data Filter:
    In this tab you see a list of the data filters of the routine. A data filter is used to verify whether the event this routine corresponds to obeys certain semantic constraints. If a runtime transaction then contains a routine that does not obey to these constraints it will be adequately marked (erroneous data status). For a detailed definition of filters, see transaction filters.

    UI Settings:
    In this tab you can define the way the routine will be displayed in transaction runtime graphs. There are 3 image types:
    'Existing Event' is the image of a routine that exits in the transaction runtime, 'Faulty Event' is the image of a routine that is not optional and does not exist in the transaction runtime or one of its data filters failed, 'Missing Event' is the image of a routine placeholder for a missing routine in a runtime transaction.
    For each of the three entries, either select an image from the already available images listed in the combo box, or click on the 'upload' link to upload a new image file.


    A group node has the following data available for configuration:
    Content:
    In this tab you see a list of all nodes (routines or groups) that exist under the group.

    General:
    In this tab you can set the name of the group and optionally add a description.

    Functions:
    In this tab you see a list of all incoming functions of the group.
    In order to define a logical edge, select first the function operator. Current, only the 'equals' operator is available.
    Next, select from the 'Source Schema' combo box the routine that will be the source routine of the logical edge. After the source routine has been selected, the fields of that routine's data source will be automatically displayed in the list below. Next, select from the 'Target Schema' combo box the routine that will be the target routine of the logical edge (only child routines of the group will appear in the combo box). After the target routine has been selected, the fields of that routine's data source will be automatically displayed in the list below. In each list, select the field that should participate in the function and click on the 'add' link to apply the function for these two fields (operands). For instance, if the source routine's data source (event) has a field called 'sessId' that should have the same value as the field 'sessionId' in the current routine's data source, select these two fields add click 'add'. If the (equals-) function that connects two routines is defined by more than one pair of operands, repeat the
    fields' selection operation with another pair of operands. Use the 'remove' link to remove pairs of operands from the function. Click the 'Add Function' link to add the function to the functions list.

    Connectors:
    In this tab you see a list of the outgoing edges of the group. You can add new edges by selecting the type of new node you wish to create and clicking the 'New Connector' link. You can remove edges by clicking the icon at the end of the row of each edge.
    When you click an edge from the list you can set the name of the edge and optionally add a description. In the 'Life cycle' field you should enter the maximal time span that could elapse between arrival of the edge's source node and the arrival of its target node. It defines the time flow constraints between two nodes. If an edge of a runtime transaction does not obey to this time flow constraint (the time span between two events was too long) it will be adequately marked, but the time status of the transaction as a whole won't be necessarily affected.
  5. The Preferences tab is divided to three tabs:
    General:
    In this tab you can set the name of the transaction and optionally add a description.
    In the 'Normal life cycle period' field you should enter the maximum time for the transaction's life cycle, that is the total time that can elapse between the creation of the transaction (marked by the arrival of the starting events) and its ending (marked by the arrival of one of its closing events). If a transaction created in one of the runs has a life cycle greater than the normal life cycle period it will be adequately marked (erroneous time status).
    In the 'Online period' field you should enter the amount of time the transaction should be regarded as online.

    Application Name:
    The data entered here defines the name that will be associated with the runtime transaction. That data originates from a data source field of one
    of the transaction's routines. Coming back to our ATM example, we would for instance like to identify each runtime transaction with the amount withdrawn, taken from a
    routine associated with a data source and filter that reflect the event of withdrawal amount approval.
    To enter the application name simply select one of the transaction's data sources. The fields' list below will be updated automatically to allow selection of the desired field.

    Advanced:
    Currently only the transaction algorithm can be selected. Select either 'Global Algorithm' or 'Linear Algorithm'.

  6. You can click the 'Update' button located at the top from time to time. After you click the 'Save' button the transaction will be saved and its topology could not be changed (changing the topology will result in creating a new transaction).

Additional links
     Projects
     Transaction Analysis