# Action Tracker

An Action Tracker is a fully configurable issue-tracking and workflow-management framework used to track items or tickets through a defined life-cycle. A workflow can be created consisting of different stages (Queues) and paths between these stages (Transitions), all of which are configurable in Kx Control.

A basic example is given in the diagram below. When an item is initially raised it is assigned a default queue of Open. The transitions are shown by the green arrows. The item can be transitioned from the Open queue to either Investigating or Escalated and from there on to Closed. Transitions can be bi-directional, which requires configuring two separate transition entities during set up.

Action Trackers are used widely within solutions built on top of Kx Platform, including surveillance and case management. Alerts can be tracked, escalated, and prioritised to allow specific actions and reviews depending on the nature of the alert.

An overview of the Action Tracker, Queues and Transitions setup, permissioned for a logged in user can be seen in Kx Control by picking Open Viewer > Action Tracker Library from the Tools menu.

## Action Tracker Management

To create a new Action Tracker, in Kx Control, select File > New > Action Tracker. Choose a unique name and package when prompted.

The following configuration can be applied.

parameter effect
Active Indicates if the Action Tracker is active
Description Purpose of the Action Tracker
Display Name Name displayed in the workspace navigator
Last Triggered Time that the tracker was last triggered
Created On Time the tracker was created
Created By User who created the tracker
Modified By User who last modified the Action Tracker
Owner Owner of the tracker: can be a user or a user group
Re-issues Indicates a new Action Tracker item will be created for an alert only if no active item exists for that alert instance and sym
Use Reissue Data When reissues enabled, whether to store reissued alert data for item
Locking Enable/Disable editing of Action Tracker items

### Queues

An Action Tracker queue indicates the current stage in the Action Tracker workflow. Considering the Action Tracker to be a trade delivery attempt, the different queues it could have would reflect the stages it would go through; open, credit check, client cancel, failed order, finished order, delivery.

The Queues associated with a particular Action Tracker can be viewed and opened from the Queues tab in the Action Tracker editor. The figure shows the typical Queue setup for a credit-alert Action Tracker;

To create a new Queue select the corresponding option in the toolbar on the top right of the Action Tracker editor.

The following configuration can be applied.

parameter effect
Action Tracker Name of associated Action Tracker
Description Purpose of the Queue
Display Name Name displayed in the workspace navigator
Owner Owner of the Queue
State Type State of the Queue*
Status Status to be displayed in the Action Tracker for this Queue
Status Color Color Picker to specify the status-box color. Can be overriden by selecting the Use default value option
Text Style Indicates text style of items in the Current Items view. Can be set to bold/italic
Show Resolution Indicates resolutions specified for any queue in a final state are to be displayed on the transition screen for an item in the Action Tracker dashboard
Time to Live (TTL) Period after which a notification is sent that the queue has not progressed
TTL Action Analytic to be used on TTL action

* Queue state is specified as:

state effect
none all Queues other than initial and final are set to none
initial if first queue in the workflow it must be set to initial
final if last queue in the workflow it must be set to final

### Transitions

Where the Queue status is set to none or initial, transitions define how an Action Tracker has passed from one queue to another. For the trade delivery example given above, where a queue (stage) in the workflow was defined as Credit Check, a logical transitional setup would be the transitions Pass check and Fail check. This would be proceeded by either passing the Action Tracker to the queue Delivery or Fail check depending on the outcome.

The transitions relating to a particular queue can be viewed in the Transitions tab of the queue editor. The figure shows a typical transition setup for the AwaitingClientResponse queue associated with the credit alert Action Tracker.

To create a new transition select the corresponding option in the toolbar on the top right of the Action Tracker/Action Queue editor. The transition can then be applied to the necessary queue configuration by setting the parameters From queue and To queue as required.

The following configuration can be applied to the transition.

parameter effect
Action Tracker Name of associated Action Tracker
Description Purpose of the transition
Display Name Name displayed in the workspace navigator
Display Form The display form will typically prompt the user to record additional information, such as task estimates. Custom forms are prepared by a q developer and should be included in the dxATTransitionDDF analytic group
From queue The queue from which the transition is activated
To queue Queue to which the transition is directed
Transition Action Analytic to be executed on the transition. Should be included in the dxATActionTransition analytic group
Notification Action Analytic to be executed for the notification. Should be included in the dxATNotificationAssign analytic group
Reassign to A user to whom an Action Tracker item is to be automatically reassigned: select a user, or check Current user
Current User If Reassign to is not specified, an Action Tracker item can be manually reassigned
Show transition popup Indicates that when a user clicks a transition button on an Action Tracker item, the display form is to be shown

### Resolutions

Where Queue status is set to final a resolution can be configured specifying the possible reasons for an Action Tracker item reaching a final status, e.g. Resolved, Raised in Error, Duplicate etc.

To create a new resolution select the corresponding option in the toolbar on the top right of the queue editor. The user is then prompted to supply an ID for the resolution and a breif description outlining the nature of the resolved entity.

## Workflows

The Action Tracker process workflows in Kx Control are DS_Launch_AT_[A|B]. These consist of;

• AT - handles alerts, item creation and any state changes
• HDB - history of all closed items plus their alerts and activity
• GW - used to query across the open and closed items
• QM - acts as a proxy for dashboard subscriptions.

The AT process subscribes to the dxATAlert messaging topic on a ds_at channel. These alert messages are generated by other processes publishing messages on that channel and each is linked to a specific action tracker. When it hits the AT process, a new item is generated or a re-issue is added for an existing one.

### Reissues

By default when an alert is published to the AT, a new action tracker item is created. This behavior can be changed with the Reissues flag on the action tracker definition.

If enabled for an action tracker, then when an alert is triggered for which an action tracker item already exists, a new item will not be generated. Instead the existing item will have it's Issue Count incremented.

An alert's uniqueness is defined by the following columns from the dxATAlert schema; actionTracker, sym, and alertkey. If the Use Reissue Data field is enabled, the re-issued alert will be used in the dashboard instead of the original one.

## Action Tracker Dashboard

The action tracker dashboard consists of a current items panel and a panel showing the details of the action tracker item currently selected.

The current items panel can be used to view all open and closed action tracker items. Various filters can be applied to narrow the number of items shown.

When an action item is selected details of the item will be displayed in the lower panel. This will include the item status (e.g. open), when the item was generated and also the properties of the alert.

### Item Actions

There are four types of actions open to the user which can change the state of action items:

• Reassigning – users can assign the ticket to other users or groups, subject to permissions
• Users can upload certain types of files which are then linked with the tickets. This requires the DeltaDaemon to be running and configured correctly. It is also possible to configure an antivirus scan to run on these files. A file can be attached to several items at once, just select them all in the current items panel, click upload and check the Apply to all selected items box.
• Transitions – users can transition a ticket between different queues (e.g. Open to Investigating).

The payload for the item can also be edited using the Edit button at the top right of the action item display.

### Reopen

Functionality exists to reopen items after they have been closed. This is implemented as a special transition. Where normal transitions link two specific queues, the Reopen transition links any final queue with the initial one. As such it's not linked to any queue in action tracker definitions and hence configured via a button from the Action Tracker configuration panel.

Other than this, the behavior is the same.

• Same hooks and behavior for transition analytics, notifications, assignments etc
• Permissionable by role
• Appears as a normal transition in the user dashboard

### Streaming view

To enable a streaming version of the items view, the dashboard component should have the Streaming Data Connection set to the ds_action_tracker connection group. This offers greatly improved performance over the polling model as the volume of data being transported is greatly reduced.

When a user opens the screen or sets filters, a subscription is made to the backend processes. This runs an initial snapshot of the items in the database and returns those to the front-end. When an item is modified, the change will be pushed to each subscription it's part of, updating the front-end views.

The volume of data handled in the streaming model is much lower than via polling, which gives the better performance. Instead of large datasets on every poll, the snapshot is only returned once on startup of the subscription and subsequent updates are only for changed rows. The snapshot can potentially be large so the dashboard component has a Max Rows parameter to limit the size. Set to -100 for last hundred rows, +100 for first hundred and 0 for unlimited.

As with the polling model, the columns returned are configurable through the component and the filters can be defined by the user.

### Locking Items

To prevent multiple users editing an item at the same time, locking can be enabled in the action tracker definition.

When enabled, items will be locked when a user begins editing. Certain user groups can be given permission to override locks on an item via entitlements in the Role Management tab of the action tracker definition.

## Entitlements

To allow a user to use the Action Tracker and be assigned tickets, the user should have permission on the ActionTracker entity group and be permissioned oo the Action Tracker entity in question.

Tickets can be assigned to users and groups with read permissions to the Action Tracker.

If a user does not have permission to a particular Action Tracker, they will not see any items for that Action Tracker.

To transition items the user will need read permissions on the relevant Queue and Transition entities.

### Role management

To enable specific user groups to perform actions on the Action Tracker items use the Role Management tab.

role effect
Override Lock Enable override of a lock on an item
Can Delete Enable deletion of comments and attachments to items

## Case management

The case management functionality exists to build groups of items by linking them together and progressing the whole case as one. As an example, in the market surveillance world, multiple suspicious trading alerts against a trader or group would be linked together to form a case. The case could then be progressed while optionally progressing the linked alerts themselves.

Case management can be enabled in the Action Tracker dashboard component using the Case Management checkbox.

### Creating cases

When enabled, this adds a new Create Action button to the dashboard component. This button opens a dialogue which allows the user to select which action tracker they want to use and the associated payload data.

A new panel to manage and display links will be included when an item is opened. The table shows the linked items and the link type. An X button exists for each row to delete the link.

The Add Links button can be used to add links to this item. The dialog allows you to specify the link type and multiple IDs to link to.

Links are defined in pairs with each pair having a main and complement text. Consider the following;

• item1 is opened and linked to item2
• Link is chosen as derives to
• item1 is stored as derives to
• item2 is stored as derives from

The available links are stored in Kx Control configuration with a default bundled with Stream called DS_AT_LINKS:DEFAULT. To specify custom link types, create an override of this called DS_AT_LINKS:AT and package with the solution instead of overriding the Kx Stream value.

### Progressing linked items

When progressing a case, the linked items can also be progressed. To do this involves a couple of steps;

• Transition of the case must have a custom Transition Analytic defined
• Analytic should call to get the links for the item (dxATGetLinks)
• Should then call to progress selected linked items with the desired queues (dxATProgressLinks)

#### APIs

Get links for an item. Returns a table of linked IDs, display name and link text.

tag name type description
param ID long Item ID
returns table Table of links
dxATGetLinks[1]
/=> id name  link
/=> --------------------------
/=> 2  "abc" "derives to"
/=> 3  "abc" "is derived from"
/=> ..


Progresses a table of IDs to the specified queues. Usually called within transition analytics to manually transition items linked to a parent ID.

tag name type description
param id long ID of item being transitioned
param items table Table of linked items to transition

Input table format is;

column type description
id long IDs to progress
queue symbol Desired queue
tab:([] id:2 3 4; queue:LateTrade.CauseIdentified)
`