|
|
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.
|
|
-
From the 'Administration' menu, select
'Transactions' to enter the transaction paradigms page.
-
Click on the 'Add new'
link to create a new transaction or click on the 'edit' link of
an existing transaction to edit it.
-
The transaction administration screen is divided to
two tabs: Visual View and Preferences.
-
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.
-
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'.

-
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).
|
Projects
Transaction Analysis
|
|
|
|
|