1.1 - Scope

1.1 Scope

This document addresses the programs, utilities and configuration of the AXT server.
Utilities for transfers, distributed commands and process control are included in this documentation.

This document provides examples for use of the AXT server for file transfers, the function of performing commands on distributed systems, relaying messages through the AXT server and the management of the actions in the AXT server.

1.2 - Detailed Overview

1.2 Detailed Overview

AXT Solution

The actions will be triggered by the client initiators (Documented in section 2.1) to perform tasks such as file transfers, command execution and messaging.
These actions will be preformed against one or more remote nodes (eg: Transfer a file from system A to system B)

To achieve the guaranteed delivery of actions, the AXT server will be required to manage the actions and report on errors in the action.
The client will also be responsible for reporting errors in the initiation of the action.
At the client, this error reporting will be done through error messages and exit codes (optional error messaging can be specified in the command flags).

The central server will be built around JBoss Application Server, JBoss Messaging, JBoss Rules and Hibernate.
Standard connectors include code from jSCH and Apache Commons:Net.

The central system also allows requeueing of complete or failed actions providing recovery ability to the administrative team.

The central server will provide the management of the actions through queuing an action message, validating the request syntax, checking access rights and initiating the action type manager.
The action managers will perform retries and alert on issues.

Figure 1

Remote Node

The remote node can communicate to the AXT server through standard tcp sockets or SSL sockets.

An action is initiated by the remote node through a message to the AXT server.

On initiation, the message is staged at the remote node by the axt-daemon for message persistency.

One acknowledgement is provided by the client daemon to the message initiator:
LCL - Locally Staged by the axt-daemon (Client persistency will ensure ACK Response)

For transfer actions (and if specified) the file to be transferred is staged on the remote node to prevent breakage of the file integrity before the staging completes.
This staged file is removed (1) after a staged acknowledgement message has been received from the AXT server or (2) when the axt-daemon determines that (a) no messages are left outstanding and (b) a pre-determined time has passed for staging to complete.

Figure 2

Central Server

When the AXT server receives the action from the remote node, it performs the specified actions and sends acknowledgments to the remote node during the different processing stages.

Response messages sent from the AXT server are:
ACK - AXT Server Received the Request APR - AXT Server Approved the Request STG - AXT Server Staged the File LOG - Action Log END - Action Ended Successfully DIE - Action Died
Upon receiving a raw message and writing it to the audit log, an acknowledgment is sent to the remote node (ACK).

The actions are validated against defined rules to determine access. If accepted, an approval acknowledgment is sent to the remote node (APR).

If the action is a transformation, the transformation is processed and the new action generated by the transformation moves forward.

Action control is transferred to the action managers (eg: Command Manager, Control Manager, Message Manager and Transfer Manager).
The managers perform the defined action by determining the best connector to call for the action (e.g.: SSH File Pull, SNMP Message Push, etc).
The best method is determined by examining the connectors available to the remote node and ordered by the connector priority.

During the action, action-specific responses may be sent (eg: STG for transfers) and relevant output is logged.

On completion of the entire message, the log is updated and the full log is sent to the remote node (LOG).

Figure 3

2.1 - Client Action Initiator

2.1 Client Action Initiator

The client initiator uses standard tcp sockets for sending the messages to the AXT server.
A socket-to-jms bridge accepts the messages and injects them into AXT.
The socket bridge maintains the connection to the client during the life of the message.

Initiators are available in C, Perl and Java.

The initiator sends the message into a local daemon (axt-daemon) which maintains the message persistency and manages stale staged files.

When the message acknowledgement (ACK) is received, the responsibility for the file transfer is assigned to the AXT server and persistency files are purged.

The client can maintain a connection after the ACK to receive information from AXT on the actions taken.

For more detail on initiators, refer to chapter 4.

2.2 - Server Message Control

2.2 Server Message Control

Message Bridge

Message bridges are used when the initiator is not capable of injecting a message through JMS (eg: non-java clients).

The message bridges are responsible for injecting the message into the AXT server and for returning acknowledgement messages to the initiator.

Current available message bridges are:

SocketBridge - provides tcp socket bridging

SpreadBridge - provides bridging to spread clients (depricated)

Basic throttling can be configured in the bridges if desired.

See the server configuration in section 3.1 for details.

AXT Queue

The AXT queue is a JMS queue provided by the JBoss Application Server.

When a message has been received by the AXT JMS message queue, an action flow is triggered.

Message Parser

The Message Parser validates the initiator message and splits the message into chained individual actions that can be managed by the AXT server.
If the message does not parse properly, the message will be rejected and notification (DIE) sent to the initiator.

Message element requirements are verified and default tags are populated where needed.
If the message does not supply the required components, the request message will be rejected and notification sent to the client.

Rules Validator

Rule verification is performed on messages that are sent to the system to determine if the message is allowed to be processed.

Rules management is provided through JBoss Rules.

Rules are based on a "deny all" policy.

"Natural Language" rules can be used such as the following test transfer rule:

rule "Test Transfer"
when
The Source defines
- the file name includes "testfile"

The Destination defines
- the name as "utsadmd01"
- the file as "/tmp/testfile"
then
Allow the whole transfer
end

These are dynamically read from a rule file in the Rules Directory defined in the server configuration.

The rules can be updated dynamically with a regular file editor by a user with physical file access to the rule file.

After the message has passed through the Rules, an approval notification (APR) is sent to the initiator.

If the message does not pass the rules, the request message will be rejected and a failure notification (DIE) sent to the client.

Message Transformer

Action transformers are defined on the AXT Server to simplify the rule setup for actions and to increase the security for requests from the initiating nodes.

Using the message transformer, new actions will be created based on the tags specified in the transformer definition. An example of this would be a definition “SETTLECREDIT” converting into a transformation tags:

• action=transfer
• src_file=/credit/settlement.txt
• dest_name=csettle
• dest_file=/post/settlefile.out

Tags that are not specified for transformation are left as is in the action: eg: leaving the source node as "nodeA" in the above example

Action Manager

The action managers are called based on the type of action that has been defined.

Action managers have to manage searching for the correct action connector based on the nodes preferences.

When a connector has been found that is prefered by the node, the connector threaded off to perform the action.

The thread(s) are managed by the action manager and are analyzed for errors.

The result of the connectors (success OR fail) are filtered through the reaction manager to determine what the next step should be for the initiated message.

These reactions are defined in the initiated message by the client and default to "END on Failure" and "CONTINUE on Success".

Action Connector

The connectors are called by the Managers based on the nodes preferred connector.

Connectors perform the action task and return success or fail to the managers.

Some connectors do return values to the client (command connector).

2.3 - Action Managers

2.3 Action Managers

The connector method is determined by the manager from the connectors available for the node and ordered by the connector priority.

If there is an action connector failure on the preferred method, the manager will choose the next method available for the node.
The manager will continue to cycle through the available connectors until the retry_count_max value is hit or until the action succeeds.

Command Manager

The command manager executes the command using the determined remote command execution connector (e.g.: SSH, RSH, etc).

During command execution, the action log is updated and the log is sent to the initiator.

Control Manager

The control manager processes the control on the AXT server directly, updates the action log returns the log with a completion acknowledgement to the requestor.

Controls are all central to administration and maintenance of AXT.

Message Manager

The message manager delivers the message to the destination node using the determined message connector (e.g.: SNMP, HTTP POST, etc).

The action log is updated with the result of sending the message and the log is sent to the initiator.

Transfer Manager

The transfer manager is broken into two managers.

There is a Transfer Pull Manager and a Transfer Push Manager.

The push manager transfers the staged file (decrypted on the fly) to one or more destination nodes.

Transfers are initially pulled to a staging area on the AXT server by the Transfer Pull Manager.
During the staging, an MD5 checksum is performed and the file is written out encrypted.

After the pull completes and if an md5 tag is present in the initiated message, the file is md5 checksum verified.
After the file validation, file staging acknowledgement (STG) is then sent to the store system.

Push transfers are pushed to the destination from the AXT server staging area with on the fly decryption.

All data files are held in the central staging area until the job is removed by the AXT purging process.

2.4 - Action Connectors

2.4 Action Connectors

FTP Connector

• Provides pulling of data files
• Provides pushing of data files
• Provides support for SITE commands through node values (as ftpSite attributes)

Note: Authentication is based on user specified credentials or credentials specified in the node values (as ftpUser and ftpPassword attributes)

HTTP Connector

• Provides sending of messages to an http host
• POST and GET type of messages are provided
• Messages will go to an HTTP message server (e.g.: OPC or MOM) for notification messages

Local Connector

• Provides pulling of data files on AXT server local file systems
• Provides pushing of data files on AXT server local file systems

SNMP Connector

• Provides sending of messages to an SNMP host
• Messages will go to an SNMP message server (e.g.: OPC) for notification messages

SSH Connector

• Provides pulling of data files
• Provides pushing of data files

Note: Authentication is based on key exchange using the central server private key, user specified credentials or credentials specified in the node values (as sshUser and sshPassword attributes)

2.5 - Action Message

2.5 Action Message

Messages must be in the XML 1.0 recommendation format and must include the proper validation line.
The header must be:

<?xml version="1.0"?>
<!DOCTYPE axt PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "/scheduler.dtd">

The full xml must be wrapped in an "axt" root tag.
The root element <axt> accepts one or more of the command, control, message, transfer or transform elements.
This format allows nesting of tasks within the <axt> element.

The requirements on the tags as well as defaults are defined in the AXT dtd file located in
/usr/local/axt/etc/schedule.dtd

Command Element

The command element accepts the following element attributes:

The command element defines the following tag elements:

Example:

<?xml version="1.0"?>
<!DOCTYPE axt PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "/scheduler.dtd">
<axt>
<command dest_retry_count_max="100">
<src_name>utsadmd01</src_name>
<dest_group>admin</dest_group>
<exec_string>hostname</exec_string>
</command>
</axt>

Control Element

The control element accepts no attributes.

The command element defines the following tag elements:

Example:

<?xml version="1.0"?>
<!DOCTYPE axt PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "/scheduler.dtd">
<axt>
<control>
<src_name>utsadmd01</src_name>
<control_name>Purge</control_name>
<control_value>7</control_value>
</control>
</axt>

Message Element

The message element accepts the following element attributes:

The message element defines the following tag elements:

Example:

<?xml version="1.0"?>
<!DOCTYPE axt PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "/scheduler.dtd">
<axt>
<message dest_retry_count_max="0" dest_retry_count_warn="10" dest_retry_delay="60">
<src_name>node1</src_name>
<dest_group>enterprise_monitoring</dest_group>
<msg_severity>major</msg_severity>
<msg_application>opc-chkproc</msg_application>
<msg_object>axt-daemon</msg_object>
<msg_text>AXT Daemon Down- Create a Sev-2 ticket and page UTS</msg_text>
<msg_group>UTS-IMS</msg_group>
</message>
</axt>

Transfer Element

The transfer element accepts the following element attributes:

The transfer element defines the following tag elements:

The src_file element defines the following tag attributes:

The dest_file element defines the following tag attributes:

Example:

<?xml version="1.0"?>
<!DOCTYPE axt PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "/scheduler.dtd">
<axt>
<transfer>
<src_name>utsadmd01</src_name>
<src_file src_file_type="B">/usr/local/axt/deploy/axt.tar</src_file>
<dest_group>dev</dest_group>
<dest_file dest_file_type="B">/tmp/axt.tar</dest_file>
</transfer>
</axt>

Transform Element

The transformation element accepts no attributes.

The transformation element defines the following tag elements:

Example:

<?xml version="1.0"?>
<!DOCTYPE axt PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "/scheduler.dtd">
<axt>
<transform>
<src_name>utsadmd01</src_name>
<transformation>SETTLEMENT</transformation>
</transform>
</axt>

2.6 - Database

2.6 Database

CADM_AUDIT Table

Columns

CADM_CONNECTOR Table

Columns

References

CADM_CONNECTORFUNCTION Table

Columns

CADM_LOG Table

Columns

CADM_NODE Table

Columns

CADM_NODECONNECTOR Table

Columns

References

CADM_NODEVALUE Table

Columns

References

CADM_STAGE Table

Columns

CADM_TRANSFORMATION Table

Columns