System Integration

March 2016

Preface

© 1992-2016 FIS.\ \ This document and the software described within are copyrighted with all rights reserved. No part of this document may be reproduced, transcribed, transmitted, stored in an electronic retrieval system, or translated into any language in any form by any means without prior written permission of FIS. FIS makes no warranties, express or implied, in this document. In no event shall FIS be liable for damages of any kind arising out of the use of this document or the information contained within.

Registered Trademarks and Proprietary Names

FIS, the FIS logo, and Integrity are registered trademarks or trademarks of FIS and/or its affiliates in the U.S. and/or other countries. Other marks are the property of their respective owners.

Confidentiality Statement

This document contains information that is confidential or proprietary to FIS (or its direct or indirect subsidiaries). By accepting this document, you agree that: (1) if there is any pre-existing contract containing disclosure and use restrictions between your company and FIS, you and your company will use this information in reliance on and submit to the terms of any such pre-existing context; or (2) if there is no contractual relationship between you or your company and FIS, you and your Company agree to protect this information and not reproduce, disclose or use the information in any way, except as may be required by law.

Disclaimer

The screens and illustrations are representative of those created by the software, and are not always exact copies of what appears on the computer monitor. Companies, names and data used in examples herein are fictitious unless otherwise noted. The material in this document is for information only, and is subject to change without notice. FIS reserves the right to make changes in the product design and installation software without reservation and without notice to users.

FIS\ 600 Lanidex Plaza\ Parsippany, NJ 07054\ USA

Document Version

8.5

Contents

Quick start

When Trax has been installed, a number of steps have to be followed in order to get the application up and running.

Obtaining a License

Before the application can be started, a valid license must be obtained from your Sales responsible or Manager. They will forward the request to traxlicensekeys after validation. New keys are generated after two business days so make sure this request is done in advance of installation. The returned license file has to be copied to C:\Documents and Settings\<user>\.trax as license.properties.

Starting the Application

{width="5.739583333333333in" height="1.1298611111111112in"}After installation of both the application files and the license, start up your server (in the template builds, this is done by means of the run.bat file, though this might differ depending on your installation and platform), this might take up to five minutes on default hardware. Look for the line ====Server Startup Complete==== to appear.

Figure 1‑1 Running the server

Once server startup has been completed, start a web browser and navigate to http://localhost:8080/trax/ from where the application itself can be accessed.

{width="4.041887576552931in" height="2.567700131233596in"}

A user name and password for system configuration will be required. This login can be requested from the integration team.

Importing Workflows

Once the application is started and you have logged on as a system user, it is time to import the workflows. Start out by selecting the folder where the base workflow is located and copy the path from your explorer.

In AvantGard Trax, go to the top menu and select Navigation > Import and paste the base workflow path into the input box. Select ok to import the data.

Once the base workflows have been imported, do the same with the corporate workflows (import the ‘common’ part before importing the corporate workflows).

Importing Translations

After import of the workflows, the translations have to be imported from the menu under Internal > Translation. Select the translation.properties file which was delivered with your workflows and import it. After import, log off, clear your browser cache and log on again.

Licensing keys

As of this version, a licensing system for the server has been implemented. This protects your investment by making sure that nobody can run copies of your software and gives you the possibility to expand your functionality at a later time by obtaining extra licenses.

Your License key will be generated by SunGard AvantGard Payments and is linked to the MAC address of your server. In order to obtain a functional key, provide the MAC address and profile name which is used to access your server.

Prerequisites

You will receive a file in order to activate your license:

The license.properties file must be located in the folder [user.home]\.trax (note the ".") This would be C:\Documents and Settings\Administrator\.trax\license.properties) When creating this folder in Windows, make sure to use the DOS command (CMD) instead of windows explorer.

User Calculation

AvantGard Trax verifies the number of named and concurrent users. If more than the licensed amount of users tries to access AvantGard Trax they are denied access until a currently active user ends his session. Under normal circumstances, the amount of concurrent users and named users will be about equal as it is advised to give every person his own user log in. This allows to track back changes to the individuals who made them.

Calculation Meaning

Method

Named Users A named user is a user who can be linked to a security profile. There does not have to be somebody working with AvantGard Trax as this user. It only has to exist with the properties set to “active” in the configuration. AvantGard Trax counts the number of active non-system users and compares this with the setting in the license file.

Concurrent This is the amount of users who are using the application at the same time. The system user is counted as a concurrent user when he is active but not when the maximum number of concurrent users has been met before he logged in.

Users

Practical Example

For named users, there can be three people called A,B and C who can use the system, even when there are only two named users available as more than one person can use the same named user. E.g. two people might share the same user account to be able to both read the payment history. In this case, A and B might both use the same named user account, with user C using his own, separate account.

If concurrent users is set to two however, only two of them can use AvantGard Trax at the same time. If it is set to three or more, all three of them can use AvantGard Trax at the same time. Suppose that the number of concurrent users is set to two; if the system user is active, only one other user can then log in. If however, two users are already active, the system user can still log in to AvantGard Trax.

Import - Export

Introduction

AvantGard Trax provides an easy solution to migrate system objects between different environments such as the test or quality assurance environment to production. This saves valuable time in that data and configuration of the system which was used for testing does not have to be recreated for implementation. The data itself is imported and exported as structured directories with XML files.

Practical Usage

The import and export function are used as follows:

Export

In order to export data, it suffices to select the data which has to be exported and to choose Export with a right-click. This will create a new file and directory structure which contains the exported items.

{width="3.892419072615923in" height="1.4375in"}

In order to export the complete navigation, you need to make sure that the export happens while the root object is selected.

Go to the menu bar > Internal > Export > Navigation

In order to export the complete menu structure, you need to make sure that the export happens while the root object is selected.

Go to the menu bar > Internal > Export > Menu

Export Location

By default, the files will be exported to c:\temp.

Import

In order to import the XML data, simply select the import command from the system menu, enter the folder where the files are stored and select OK. The files and subdirectories are scanned and automatically processed.

Note that only files beginning with import_ will be imported.

{width="2.6in" height="0.6569444444444444in"}

When importing files, the following rules apply to the imported data:

XML Data Database records Database records

               Before Import      After Import

exists exists XML data is imported into database and the original data in the database is overwritten.

does not exist exists existing database records are kept

Change Approval interaction

Note that it is impossible to import data to which change approval has been applied (See the change approval documentation for more information) as importing this data would invalidate the change approval process.

Availability (Integrator)

The availability of the import and export functions is only available to integrators. The rules used are ImportXml and ExportXml.

Limitations

The following has to be taken into account when using the import and export functions:

This is not an upgrade function, only a migrate function. In other words, data can only be exported between applications of the same version number.
Import is applicable to an entire directory at once. All XML files in this directory, beginning with ‘export_’ will be processed.
Both the navigation and menu are exported as integral sets. It is not possible to export part of the navigation or menu structure.

Export Location

To modify the location to where the data is exported, the ExportXml rule sequence has to be changed to point to the desired location. This is done as follows:

System > Rule Library > Rule Sequence > select the ExportXml rule > edit > Rule Invocation > ExportXmlRule > edit > Rule Invocation Parameter > targetDir > edit > change the value to the desired location.

Exportable.properties

The list of exportable models, entities and attributes is defined in the exportable.properties file which is located at jboss/module/com/trax/config-ear/main/config. Note that this list should not be edited, it is there to give you an overview of which inventories will have the export option.

If the exportable.properties file is missing then an error message is be logged in the log file and no export actions will be available.

Workflow Modifications

Workflow

A workflow is defined by its Code, Name and Description attributes and has the following functional attributes:

Subject The subject of the entities going through workflow.

Cancel state If configuration errors are detected during processing, the workflow object moves to this state.

Initializer The initializer rule sequence that initializes the entity entering the workflow.

Error Handler The rule sequence that is called when the incoming data contains errors. One implementation is available in the product that creates an XML version of the error collector and stores it as a value object in the database. But projects can easily create their own error handler.

Direction Incoming or Outgoing (Inbound or Outbound).

Use for incoming routing Does the workflow need to appear in workflow list of incoming routing?

Use for outgoing routing Does the workflow need to appear in workflow list of outgoing routing?

Incoming (tab) The inventory codes for specific (incoming) communication states.

Outgoing (tab) The inventory codes for specific (outgoing) communication states.

Transition (tab) The transitions with their attached rule sequence to invoke and an optional notification to send.

                         The ‘Automatic Transitions’ checkbox controls whether the rule sequences are invoked automatically or not.

{width="4.753731408573929in" height="3.3081528871391077in"}

{width="4.770833333333333in" height="3.349735345581802in"}

Bulk Payments

Enriched

Enriched bulk payments have to be validated by checking the Account number, BIC or ABA code and format. This can result in two possible outcomes: Either the content and format validation is passed and the payment is VALID or the validation fails and it is INVALID.

Invalid Payments Algorithm

2 types of validation algorithms can be used for handling invalid payments/envelopes. They can be configured by setting the ‘invalidPaymentAlgorithm’ parameter in the ‘RemoveInvalidPaymentsRule’ of the ‘BP-validate’ rule sequence:

NewInvalidEnvelope: when an envelope contains invalid payments, the invalid payments are split off into an invalid envelope and the valid envelope is sent back to the beginning of the workflow.
InvalidateCurrent (default): when an envelope contains invalid payments, the top level envelope is set to invalid.

The ‘RemoveInvalidPaymentsRule’ repositories can be configured:

invalid-repository (BP): defaulted to BP_ENV_INVALID
valid-repository (BP): defaulted to BP_ENV_VALIDATED
old-repository (BP): no default, if supplied, must match file envelope repository to move from (in order to move to invalid)
invalid payment repository (UP): defaulted to UP_PMT_INVALID

{width="4.716666666666667in" height="2.7916622922134735in"}

{width="3.562800743657043in" height="2.800333552055993in"}

Manually rejected

Invalid payments or envelopes can also be removed manually using the Remove action within the payment grid. In that case the selected payments will be unlinked from their envelope and will be moved to repository « BP_PMT_REJECTED_MAN » (configurable using the unlinkedPaymentsRepository parameter of the WebUpdateEnvelopeRule within the PersisEnvelope rule sequence). Removing an envelope behaves the same as if all payments of that envelope would have been removed. While unlinking Ordering Customer Account information is copied from batch to payment level (configurable using the copyOrderingCustomerAccount parameter of the WebUpdateEnvelopeRule within the PersisEnvelope rule sequence) and processing history is added on the payment indicating that payment was manually removed.

Status Feedback Workflow

Prepare matching reference

The ReadyToSend rule sequence contains the ApplyDecisionTableRule. This rule decides which field to copy to the reconciliation reference by determining the payment target format code and referencing the PrepareMatchRef table to see which reconciliation rule to apply.

Reconciling

The ReconciliationRule rule, used to reconcile status feedback messages with value objects and which updates these value objects with the appropriate ISO status and reasons, can be fine-tunes using following parameters :

The matchingFactory controls the way payments and envelopes are looked up.

Not specified: the default relaxed matching is used which expects the filters to be expressed in XPath notation.
StrictPaymentMatchingFactory: a strict algorithm is used to match the payments and envelopes taking into account the matching reference of the parent.
com.trax.payment.matching.PaymentMatchingFactory (= default):\ a powerful relaxed matching which expects the filters to be expressed in HQL notation and the propagationClass to be com.trax.payment.matching.PaymentPropagation.
com.trax.payment.matching.StrictPaymentMatchingFactory:\ a powerful strict matching which expects the filters to be expressed in HQL notation and the propagationClass to be com.trax.payment.matching.PaymentPropagation.
If the propagationClass not specified the default propagation is used to propagate the reconciliation status through the envelopes and payments. If specified custom propagators can be used to control how the status is propagated. com.trax.payment.matching.PaymentPropagation should be used when using powerful relaxed or strict way of matching.
The skipStatusCodes contains a comma separated list of ISO status codes which are skipped during reconciliation.

Payment Screening

Indexes

Fraud list detection can be configured by selecting the fields on which detection should happen. Each customer has a different preference on fields to use. Trax has an index on a number of most used database columns. If you select different fields, make sure to create an index on those database columns if needed.

Following fields already have an index :

Field Database column

Data owner GEN_CRIT_DO_ID Currency GEN_CRIT_CCY_ID Ordering bank account GEN_CRIT_OBA_ID Ordering holder GEN_CRIT_OH_ID Ordering bank GEN_CRIT_OB_ID Internal class. Type GEN_CRIT_ICT_ID Source system GEN_CRIT_SRC_SYS_ID Payment method GEN_CRIT_PAY_MTH_ID Counterparty holder name HLD_CRIT_BEN_NAME Counterparty bank account number BNK_CRIT_ACCT_NBR

Navigation Configuration

Introduction

Configuring the inventories, actions and entities is part of the responsibility of an integrator. From his available sets, the user administrator can then choose subsets which are finally exposed to individual users. The diagram below gives an overview of the different responsibilities. This chapter will deal with the integrator responsibilities, those of the user manager can be consulted in the reporting and user administration chapters.

{width="5.821782589676291in" height="2.6048622047244097in"}

Entity Selection

The entity selection determines the displayed columns and their translations.

{width="5.361111111111111in" height="2.8944444444444444in"}

You choose the columns you want displayed from the list of subjects on the left, list them in the middle column and determine their sorting order in the right column. The code, name and description fields are used to identify the entity selection. Do make sure that the code is unique, both to prevent confusion and to make sure the system is able to correctly identify the entity selection.

Determining the Columns to display

Once the entity has been selected from the drop down list, the subject list will be populated (the column on the left). From there, you can select the fields which you want to have displayed by selecting them and choosing add or double-clicking them. They will then appear in the columns column.

Determining the Column order

In the columns column, you can set the horizontal order of the columns and remove unwanted columns. Use the buttons at the bottom to set the order (up, down and remove). Items at the top will be columns on the left, items at the bottom will be on the right of the resulting inventory.

Choosing the Column Headers and their Translations

In the columns column, select the column of which you want to change the header or translation and choose the Translations button at the bottom. A dialog box with the four translations will pop up where you can set the column header names in the available languages.

{width="2.0104166666666665in" height="0.9971675415573054in"}

Choosing the Sorting for the Displayed Data

The data in the columns can be sorted as well. When no sorting is applied, the order in which the query returns the results will be used. To add sorting, select the desired column from the columns column and double click it or select Sorting from the bottom menu. The column will be added to the sorting column on the right. Here it can be moved up and down depending on the order of sorting importance. Top items are the primary sort key, next item will be applicable if the primary items have the same content and so on. The table below illustrates this. The direction button allows to set the order to ascending and descending.

1st (asc.) 2nd (asc.) 3rd (desc.) What determines the order

a a a Globally, 1st column a ascends to b to c

                                      1st column is equal, 2nd ascends a to c.

a c d

b b c Globally, 1st column a ascends to b to c

                                      1st and 2nd are equal, 3rd ascends c to a

b b a

c d b Globally, 1st column a ascends to b to c

Special cases

If the selection of an inventory contains following xpaths:

Payment.Payment:instructedAmount/amount
payment.Envelope:instructedAmount/amount
SigningAdministration.Mandate:maximumAmount
SigningAdministration.Mandate:maximumCounterValueAmount
SigningAdministration.Mandate:minimumAmount
SigningAdministration.Mandate:minimumCounterValueAmount
SigningAdministration.DayLimitConfiguration:dayLimit/amount
SigningAdministration.DayLimitConfiguration:counterValue/amount
SigningAdministration.DayLimitUsage:usage/amount
SigningAdministration.DayLimitUsage:configuration/dayLimit/amount
SigningAdministration.DayLimitUsage:configuration/counterValueAmount

AND that selection is followed by a xpath that points to the corresponding 'currencyCode', in those cases we will use a specific formatter that will show the amount in nbr of decimals of the currency code column

If the selection of an inventory contains following xpaths:

Payment.Payment:counterValue/amount
Payment.Envelope:counterValue/amount

in those cases we will show the amount in the user currency iso the trax currency if the user has one configured with nbr of decimals of that currency code

If the selection of an inventory contains following xpaths:

Payment.Payment:counterValue/currencyCode
Payment.Envelope:counterValue/currencyCode

in those cases we will show the the user currency iso the trax currency if the user has one configured

Entity Configuration

In entity configuration, you can (de)activate data ownership, choose the desired entity selection and

set a default screen.

{width="4.020833333333333in" height="3.4375in"}

Field Contents

Entity This is the entity to which this configuration will apply. Only one con- figuration per entity is possible. Data ownership en- abled When this field is set to true, data ownership will be enabled on this entity. Please refer to the configurator guide. In brief, data owner- ship allows you to split data access between organizational entities. Audit capable This is a system setting to determine if the entity is audit capable. Audit can only be activated if this property is true Audit enabled If set to true, changes to this entity will be recorded in audit records Change approval Change approval can be off, 4-eyes or 6-eyes. This means that data modifications are accepted at once, only after review by another person or after review of two people. For more information on change approval, please refer to the configurator guide. In order to use change approval, data audit must be enabled. Communication en- abled When activating the communication enabled option, a link is laid be- tween the communication information and the business object (payment, envelope, message,... A Communication History tab will appear in the details screen of the business object, containing communication information (Incoming and Outgoing) of that particular business object. A view button is provided to show more details of this communication. The link between the communication information and the business object is also available on the communication object itself where the corresponding business object is shown in the Business Entity tab showing the business entity and its unique identifier. Visible The visible field determines if this entity is available for the query builder. If an entity is visible it is possible to create queries on it, otherwise it will not appear in the drop down list of available entities in the query builder. Selection Here you can set an entity selection for an entity (See 4.2Entity Selection6.2 “Entity Se- lection” ) Note that this entity selection can still be overridden by a selection which is chosen in the inventory screen (See 6.6 “Inventories” ) Screen Used to open a specific XGL screen for this entity. DefaultVO Used to select a default valueobject

Enabling Data Ownership

In order to enable data ownership on an entity, check the data ownership enabled checkbox on the entity configuration screen for that inventory.

Enabling Audit

In order to enable audit on an entity, check the audit data action checkbox on the entity configuration screen for that inventory, provided that it is audit capable.

By default, audit is enabled for 7 entities:

System.User
System.User Group Membership
System.User Identifier
System.Data Owner Membership
System.Certificate
System.User Profile
Reporting.Reporting User Profile

Enabling Change Approval

In order to enable change approval on an entity, make sure it is audit capable, check the audit data action checkbox on the entity configuration screen and select 4- or 6-eyes change approval for that inventory. Entities with parent-child relations are automatically enabled/ disabled for these options together. Do note that change approval may never be activated without audit as the audit records are necessary to determine the actual change which is approved. (take special care with EBICS entities, as it is technically possible to have them set to change approval with audit missing, so it is necessary to verify that all components which are logically grouped together to have the same change/audit properties.)

Actions

Actions are executions of rule sequences with predefined parameters or they call up specific screens.

{width="4.218772965879265in" height="3.905660542432196in"}

Creating a new Action

In order to create a new action, select new in the action inventory and add the desired properties of the action.

Field Contents

Code Code of the action. This code has to be unique and is used to identify actions when adding them to inventories or menus. For this reason, please refrain from using cryptic codes and make them as transparent as possible. Description Description of the action, this should be preferably a human-read- able description to help administrators in determining the purpose of the action. Parameters The parameter to execute, this is a ;-separated list. Confirm Presents a dialog box for confirmation before execution Input type This determines the input type to which the action is applied. This can be none, single ID, multiple ID, single value object, multiple value object, file or communication. Rule The rule sequence to call. Event Used for client side events (for example select all, which has no communication to the server) Output type The type of output which can be undefined, none, screen (opens a screen) or file (results in a save as dialog box) Screen Used to open a specific XGL screen Input screen When you want to pass additional parameters to your action, you can use the input screen to capture them Note type You can specify which note you want to show up on an action by selecting a note type on it. Edit This should be deselected to create a read-only variant of the screen. Refresh Select this to refresh the contents of the list view. Note that this has an impact on performance.

Changing the Translations for an Action

On the translations tab of the action, translations for the four available languages can be entered. Note that this can be done in the system-wide translations inventory as well. The inventory presented here is simply a convenient alternative.

The menu defines the menu structure and where actions are located in the menu. To edit the menu, select Internal > Menu form the menu bar at the top of the application. It is not possible to create new actions here, they can only be added, have their location in the menu defined or be removed here. The info button can be used to view the action details. The menu edited here should be seen as a structuring tool for menu items. Use the + symbol to expand the menu items down to the action level.

The menu bar is globally defined and each security profile has access to a subset of the global menu bar. This means that menu items will be located in the same menu structure for all users, but each user only sees the items which are available to him. For example, the global menu will include imports for all country-specific formats, but a security profile might only have access to the European formats. The other items will not be shown to him/her.

{width="4.017227690288714in" height="4.116137357830271in"}

An action is added by selecting a location on the menu structure and selecting the Add action button and choose the desired action from the list. A menu item is added by the New menu button which presents the option to enter the menu name and translations. Either of these can be selected and removed with the remove button.

Note that once a new menu item has been added, the translations can be edited by using the info button.

To change the order of actions and menus, you can select them and use drag-and-drop to bring them to their desired position. The blue line indicates where the dragged item will be positioned after release.

{width="1.8229166666666667in" height="1.0729166666666667in"}

Inventories

The inventories determine what data is shown in the inventories by applying filters and determine what actions are possible per inventory. Settings can be modified for existing inventories or new inventories can be created with specific actions or filters. Take great care to make sure that end-users are not able to create their own inventories as this would undermine the security and workflow procedures and can lead to instability of the application.

Creating an Inventory and Filtering Data

An inventory is created/edited by going to the inventory called inventory at System > User management > Inventory and either selecting one followed by edit or choosing new.

The Inventory should have a unique code, a name and a description, the inventory type field is used to select the inventory type, by default the inventory type field is ‘Classic’ and user can select URL also. When the inventory is type is ‘Classic’ then the subject should be chosen from the list and optionally, if the default list of displayed columns for the inventory is not what is desired, a selection can be chosen. This optional selection here supersedes the one which can be set on entity configuration which in turn supersedes the one on entity selection.

By default, all records for a chosen subject will be shown, but this might not always match what is desired. Hence a filter can be created to limit which records should be displayed for an inventory.

To add items to the filter, select them in the subject tree and double click them or perform a right click and select filter. The items will be added to the filter from the subject list. On the filter itself, use the AND/OR button to change the conditions, add, remove or edit specific parts of the filter and use expert mode to enter the query directly.

For more information, please refer to the Query Builder documentation in the Administrator guide.

When Inventory type is selected as URL, screen will be changed and new field “URL” will be added, User can set url for example: ‘https://www.sungard.com/solutions/corporate-liquidity/payments-factory’. This URL inventory will display the URL page when user clicks on an inventory and it is of type URL, then display the URL on the right hand side (just like for Nodes)

{width="3.525647419072616in" height="3.759739720034996in"}

{width="3.4770833333333333in" height="4.097402668416448in"}

The following options exist for relative times and dates.

T: Returns todays date. For date fields, this is interpreted as the date only, for date-time fields, this is interpreted as today at the beginning of the day. (00.00 hours)
N: Now (The date of today plus the current time)
D: days
H: hours
m: minutes
s: seconds

Allowed operators for relative dates are

Examples

tomorrow: T+1
today when using a date-only field: T
yesterday: T - 1
30 days ago: T - 30
30 days in the future + 30

Everything from today when using a date-time field: (> (T) AND < (T+1)) because it starts at today (00:00) and ends at tomorrow (00:00).

Everything between 60 days ago and 30 days ago: (>= (T-60) AND <= (T-30))

Everything between 30 and 60 days into the future: (> (T+30) AND < (T+60))

All payments with a cut-off time within the hour: Payment.Payment[cutoffTime > 'N' and cutoffTime < ('N + 1H')]

Notice the difference in behavior when using a date or date-time field as for dates, the entire day will count, while for date-times only the date at midnight in the morning counts.

Special Cases

In order to check for empty fields "null" can be entered in the condition field. =null corresponds to empty fields, <>null corresponds to non-empty fields.

Wildcards can be used for filters as well. The % character will replace multiple characters.

When selecting values: the filter x > 010 will result in all values larger than 10. (e.g. 0099 and 090 are valid, but 009 is not.)

When selecting text fields, the filter x > 010 will result in all data where the first three characters are larger than 010. (e.g. 090 is valid, but 0099 and 009 are not.) In text fields letters have a larger value than numbers (e.g. a > 1)

Editing the list of Allowed Actions

Every inventory has a list of allowed actions and an order in those actions (which actions are first in that list). From this list of actions, a subset can be chosen per security profile (for example, certain profiles are allowed to view data, but not to edit that data). The actions tab of the inventory is where this list of allowed actions is configured.

{width="3.40625in" height="1.6458333333333333in"}

To add an action, select the Add button and choose the action from the presented list which will then be added to the bottom of the current list. To remove it, select the action and pick Remove. The order of actions is edited by selecting the action and choosing the Up or Down buttons and a separator is added by clicking the Add separator button.

Setting the Default Action for an Inventory

The default action is chosen in the inventory menu on the actions tab. There, you choose the action which is to become the default and then choose Default at the bottom of the menu.

{width="3.3875in" height="1.3555555555555556in"}

Changing the Translations of an Inventory

Inventories have their own translations on the translation tab. These same translations can also be edited via the central translation inventory which is available to the integrator via System > GUI > Translations. Having them also here simply allows for easier editing.

{width="3.4895833333333335in" height="0.96875in"}

Adding a Counter to an Inventory

The counter mechanism counts the number of records or objects retrieved from the database and displays this number next to the inventory itself. Note that the number of existing records is shown, not the actual number of records displayed as this can differ due to activated filters. The counter is enabled on the additional fields tab of the inventories detail screen. Check the checkbox to have the counter displayed for the inventory. In addition, the auto refresh option can be activated to keep the counters up to date. The refresh interval should be specified in seconds and if no interval is entered, the default interval of ten seconds is used. Do note that this impacts performance.

{width="3.4131944444444446in" height="1.8097222222222222in"}

Adding Alerts to an Inventory

Inventories can trigger an alert symbol for different conditions (most commonly when empty or when not empty). The desired condition for the alerts can be set on the additional fields tab of the inventories detail screen. In addition, activating auto refresh and choosing the interval for refreshing (in seconds) will make sure that the alerts and counts are regularly updated. Note that auto refreshing consumes additional resources since a connection to the database is made during every refresh. If no interval is entered, a default interval of ten seconds will be used.

{width="3.125in" height="0.7291666666666666in"}

On Screen Filtering of Inventory Data

There are two ways to filter data within an inventory. You can create an expression at runtime which must be matched by the available data, or you can have default on-screen filters.

You can create a filter at runtime by right clicking on the column header and entering the characters which must be matched. (%Pay in the example below which means any word with the letters Pay in them and respecting the case)
A search screen can be added to an inventory. This is done on the additional fields tab. The screen itself is selected from a list of XGL screens and the way it is displayed is selected in the Search option. It can be set to None, Collapsed, which means you have to expand it to use it, Available, which means it can be used, but is not required and finally required, which means that filter data must be filled out before the content of the inventory is shown. This last option is used to prevent inventories from overwhelming the database which could cause delays in the system.

{width="1.0625in" height="0.7395833333333334in"}

{width="5.760416666666667in" height="0.9583333333333334in"}

Refreshing Inventory Data

When you want to periodically refresh the contents of an inventory, the auto refresh option on the additional fields tab can be used. The refresh interval should be specified in seconds and if no interval is entered, the default interval of ten seconds is used. Do note that this impacts performance. This refresh interval will refresh both the counters (if activated for that inventory) and the contents.

{width="3.40625in" height="0.40625in"}

The Inventory Context

The context of the inventory can be used to pass on additional information for that inventory. Trax security is managed by a security manager (com.trax.framework.security.SecurityManager), defined in application.properties. The default implementation is com.trax.system.usermanagement.DefaultSecurityManager, but this can be extended by adding new security rules or SecurityInterceptors (com.trax.system.usermanagement.SecurityInterceptor) or it can be replaced for specific projects. There is one default security interceptor in the template which adds the security rules for reporting: securityInterceptors=com.trax.reporting.ReportingSecurityInterceptor.

The security manager & interceptors get the query / CRUD request and the user that is requesting it as input. Sometimes it is necessary to give more context to the security layer. To do this you can add parameters to the query. This is done in java code with the following statement: query.getParameters().put("aaa","bbb").

For GUI Inventories, the context field can be used, this will add the "context" parameter to the query. For example if you set context to signing then the security manager will know to invoke the signing logic.

The navigation is located at internal > Navigation and defines the global order of inventories. Per security profile, a subset of this navigation is used. This means that menu items will be located in the same navigation structure for all users, but each user only sees the navigation items which are available to him.

The translations are used both on screen when showing the navigation to a user and within the security profile where they can be selected to be accessible from that profile, but the codes are shown when configuring the navigation here.

Note that for this chapter the word navigational element will be used to mean a navigational grouping element. In the example below ApplicationData, UnitaryPayments, AS, NEW_NAVIGATION, ID, ID_Workflow are examples of these navigational grouping elements. They act as higher-level folders.

{width="3.086956474190726in" height="2.768904199475066in"}

You can drag and drop inventories and navigation folders from within the navigation screen (menu Internal > Navigation). The location where the dropped item will be placed will be marked with a blue line and triangle.

Inventories/elements are added to the navigation by selecting internal > Navigation from the menu bar and choosing where you want to add the navigation followed by New navigation or add inventory. A new navigational element is entered as text with the four translations, an inventory can be selected from the list which will appear. This list includes only the unused inventories to prevent duplicate entries.

Note that when you create a new navigational element and want it to be on the top level, you will have to drag it to that position after creation as by default it will be part of an existing navigation element.

In order to have this change reflected in the application, you must also update the security profile (check the checkbox next to the new inventory/navigational element).

Custom URL

The Tree nodes in the navigation can now point to an external URL. If the URL is not empty, selecting the node in the GUI will show that URL in the right inventory pane. Ba aware, the browser will not allow to mix HTTPS and HTTP pages.

Addenda: The Counter Mechanism

Introduction

This information is provided in near real time, but changes made to the data in the database by other users or server side processing might cause the count to deviate from the actual number of records. This approach minimizes the performance impact on the server when dealing with multiple users.

Triggers

The counting function only operates at user initiated instances as continuous real-time information would consume too much resource on the server. The counting function is thus triggered by certain events.

By accessing the top-level folder, the counter will retrieve information for all inventories belonging to this folder. Inventories for which the count has not yet been retrieved show empty parenthesis () until their count has been retrieved. The counter retrieves data for the top most inventory items first and then works its’ way down to the bottom of the list.
A recount for all items belonging to a top level folder can be manually triggered by clicking the refresh button (next to the ‘Menu’ label).
When selecting an inventory from the top-level folder, a recount for this inventory is triggered in order to provide the latest possible information.
When modifying (adding/deleting) records in an inventory, the counter is updated to reflect the actual number of records for that inventory.
When changing the selected Data Owner in the top right, the, the counter is updated to reflect the number of records which comply to that selection.

Multi-Entity Adaptation

The counting mechanism takes into account the data owners to which the user has access in case multi-entity has been provided. This means that the counted records for the inventory will reflect those records to which the user has access in compliance with the data owner he has selected.

When data owner membership has been changed in user administration, the result of this change will only be visible after restarting AvantGard Trax on the client side. This applies to both the counter and the data owner filtering ability.

Performance

The performance of this feature is influenced by a number of factors and careful setup is necessary in order to minimize the amount of system resources necessary for fluent functioning.

Proper setup of the inventory items for which the counting function is desired. As more counters require more resources from the server, counters should only be configured for those inventories for which they serve actual purpose.
The database server capabilities determine the response time of the counter. A more powerful database server will have to dedicate a smaller percentage of its’ resources to the counter.
The number of concurrent users has an effect on the resources which the server must assign to the counter functionality. The more users who access the inventory with a counter set up, the higher the load on the server will be.

Decision Tables

Principle

Decision tables are a part of AvantGard Trax which allows modifications to the workflow, depending on conditions of the object to which they are applied. For example, payments can be validated differently, depending on their content or those for a specific customer can be saved to a different directory on drive or in a different format.

Decision tables are used when objects like payments and envelopes have to be processed differently, depending on their content. A decision table will apply filters to the content and see what matches. When a matching filter is found, the rule sequence associated with that filter is executed.

The decision table system consists of a number of decision tables. Every decision table can be called from a rule and will then take each object separately and try all filters until either a match is found or the filter list has been exhausted. It will then take the next object and try the filter list for that object.

A decision table is applied when called by a rule sequence in the workflow.

In essence, a decision table can be portrayed as follows: (more than four are possible, but not illustrated for brevity).

Filter Condition

The first filter is tried to see if the object matches. If it matches, the rule sequence associated with the first filter is executed and the decision table is exited. If it does not match, the second filter is tried. When possible, the filter with the highest chance should be put first so that the other filters do not have to be tried. However, the filters are consecutively tried when no match is found, so the first filter should be as specific as possible.
If the first filter was not matched, the second filter will be tried. For this reason, the second filter may not be a subset of the first filter, because then it will never match.(e.g. if the first filter is all payments over 10.000 euro, then the second filter should not be between 10.000 and 20.000, since those payments have already been processed by the first filter and exited the decision table.)
The third filter is tried for those objects which haven’t matched with the first or the second one.
Ideally, the final rule should catch all objects which have not been caught by the previous rules.

Invocation

The decision tables are located under System > Decision support.

The logical sequence to call a decision table is as follows: A rule sequence invokes the rule “ApplyDecisionTableRule” with as invocation parameter the name of the table code. The table is then used to see which filter is the first to match and the associated rule sequence is then executed.

Rule Sequence

The following image shows how the rule sequence is linked to the decision table:

{width="5.3180555555555555in" height="5.302083333333333in"}

ApplyDecisionTableRule

The rule ApplyDecisionTableRule applies the decision table and takes as parameter the table code (the table code of the decision table which is to be used).

Configuration of the Decision Table

Different decision tables can be set up, each for a separate rule in the workflow. To see how the workflow determines which decision table is to be used, see the previous chapter.

To create a new decision table, right click and select new, to edit an existing one, right click on it and select edit.

Decision Table Properties

{width="3.4583333333333335in" height="1.09375in"}

Field Content

Code The code for this decision table. The table will be referred to by the apply- decisiontablerule by means of this code. For this reason, an easily recognizable code is advised. Name The full name of the decision table. (Serves only information purpose). Subject The subject to which the decision table is to be applied.

Decision Table Filters

The next screen shows the conditions against which the object is checked. If a match is found, the action linked to that condition set is executed.

{width="3.4270833333333335in" height="1.0833333333333333in"}

Each table consists of one or more filters. The object to which the table will be applied is now checked against the first filter and if it matches, the action which is linked to that filter is executed. If it does not match, the next filter in line is checked.

Please note that the filters are not able to process numeric fields such as dates or amounts. The individual filters are configured as follows:

General

In the general tab, the order number has to be selected (it is advised to use a multiple of ten so that later on, extra filters can be added in between without having to renumber all filters. e.g. 15 can be added between 10 and 20 later on)

Next to the general tab, the Decision Action has to be selected. This is the rule or script which has to be executed when the filter matches.

{width="3.3854166666666665in" height="1.09375in"}

Condition

On the condition tab, a filter, rule or Groovy script can be entered which must be matched.

{width="5.722916666666666in" height="3.3986111111111112in"}

Action parameters

The action parameters define the parameters which are to be applied when the action, associated with this filter is to be executed. (e.g. to which directory a file must be written). For more information, refer to the documentation regarding communication.

Note that the action parameters only contain drop-down lists when this has been programmed into the corresponding decision table category class. (in our example com.trax.message.gui.decision.CommunicationParametersPanel) If there is no class linked to the decision table category, there will only be an empty text field where the parameters and their values can be entered. This means that the parameters must be known to the end-user. Therefore, it is preferable to implement a decision table category class if the end-user is supposed to make modifications to the decision tables. This will help to minimize mistakes and make the system easier to use.

Field Content

Channel The communication channel Workflow The workflow Parameters Optional parameters which are to be applied to the executed action.

Decision Actions

Decision actions contain either a rule or a script which is executed when their linked entry in the decision table is matched

{width="2.6041666666666665in" height="1.3229166666666667in"}

Application Logging

Logevent

Using the ‘logevent’ rule within a rule sequence it’s possible to log a specific application log. This rule has following parameters :

logeventCode (mandatory): referring to the application code you want to log
logeventLanguage (optional) : possibility to configure which application code translation should be used
logeventParameters (optional): possibility to add application log parameters using a comma separated list of parameters {parameter key}={parameter value} where parameter value can be a constant (surrounded by a single quote) or a jxpath (example: name1=’value1’, name2=ownReference)

Customizing Printing and Classic Reporting

Standard Printing

AvantGard Trax has a 'Print' action that is commonly available in various workflows and that generates an HTML page for printing purposes. The same function is also used when creating html output using the embedded query builder in AvantGard Trax.

Note that when printing an object that has slave relations and those slaves have other slaves (e.g. rule sequence, security profile, menu,...), these last ones will result in an empty column.

Modifying the Stylesheet

The first step is to modify the style sheet which is used by Trax to generate the html output. This style sheet is part of the Trax build. For the template project it is part of the 'template.ear' file. In the standard JBOSS template project, the ear file can be found in the following path: <Trax JBOSS server path>\server\default\deploy.

In this directory, you will find the template.ear file. Open this ear file using eg winrar will result in the view below:

{width="1.15625in" height="1.53125in"}

Open the APP-INF folder and subsequently select the lib folder. In this folder, select the 'generics.jar' file and click on the 'View' icon. The style sheet that needs to be updated is called template.html.xsl. Drag and drop the style sheet on the desktop or on the file system and open it in an xml editor.

{width="2.220138888888889in" height="1.3930555555555555in"}{width="1.53125in" height="1.8125in"}

{width="5.6875in" height="4.385416666666667in"}

First, change the width and the height parameters to the number of pixels of your logo file. You can see this in the file explorer by selecting properties to see the dimensions.
Secondly, refer to the file name of the image file containing the logo. In this example, the file name is 'ps.png'.

Adding the Image file

Open the template.ear file again using winrar and select the webstart.war file. Click on 'view' icon in the winrar menu tool to open the webstart.war file. Add your logo file (in our example ps.png) to this archive by adding the file which is case sensitive. The name should match the one given in the style sheet.

{width="1.648611111111111in" height="1.573611111111111in"}{width="1.09375in" height="1.5625in"}

Printing workflow object

Besides the ‘Standard Print’ action which is commonly available in most inventories, AvantGard Trax also contains a more flexible Print mechanism, typically used for printing workflow object, which uses a dedicated configuration entity called ‘Print Table’ (Message model). An inventory for the ‘Print Table’ is integrated in the SA (System Administration) security profile.

Configuration

A new action called ‘PrintReport’ which triggers the ‘PrintTableRule’ rule, can be used for this more flexible way of printing workflow objects. This ‘PrintTableRule’ rule has 3 parameters :

print-fileName (optional) : specifies the file name pattern of the print output (may contain placeholders)
print-tableCode (optional) : specifies the print table that should be applied (overrides default behavior)
print-context (optional): extra filter matching with ‘context’ field of the print table (ignored when using print-tableCode parameter)

Within a ‘Print Table’ following attributes can be configured:

Field Content

Code Code of the print table Name Name of the print table Description Description of the print table Workflow Optional: matching with the business workflow of the workflow object to print Data owner Optional: matching with the data owner of the workflow object to print Language Optional: matching with the language of the user who performs the print action Target format Optional: matching the target format of the workflow object to print. Internal classification type Optional: matching the internal classification type of the workflow object to print (selection list depends on selected workflow) context Extra filter criteria not originating from the workflow object provided via the parameter ‘print-context’ of the ‘PrintReport’ action Format Mandatory: output format used for printing, listing format definitions with format factory engine type BIRT or XSLT. Print parameter Optional: allowing to feed parameters to the output format which was selected (these parameters DO NOT override the parameters set on the format definition itself)

How to configure Report or XSLT format definition is explained in chapter 4 of the Admin-Formats manual.

Printing

The ‘PrintReport’ action selects, based on the ‘Print Table’’ configuration, the print output format. This is done using the criteria workflow, data owner, language, internal classification type and context as configured within the ‘Print Table’ where only non-empty criteria of your ‘Print Table’ are considered. In case more than one ‘Print Table’ matched the most specific is used, in case no ‘Print Table’ matches an error message is shown (Unable to determine Print Table). This default behavior of determining the appropriate ‘Print Table’ and as a result print format can be overridden using the print-tableCode parameter.
The ‘PrintReport’ action allows multi selection of workflow items to print. But in this case it is possible that, during determination of the appropriate ‘Print Table’’ configuration, multiple (most specific) Print Tables are matched. An error message will be shown.
Also, if selected value objects for printing contain specific data differences (target encoding, place holder values used within the generated filename (like ownreference)), the values of the first selected value object are used for the output of the print.
The print result will :
be shown in a separate tab of the browser in case the extension of your output file (configured using the print-fileName parameter) equals ‘html’, ‘htm’ or ‘txt’
trigger a save as in all other cases

Classic Reporting

Two actions are used to generate the query results:

GenerateHTMLreport for an HTML report in a new browser window
GenerateCSVReport for a tab-separated file on disk

Parameters

base: the base URl where the resources can be found. By default this will be com/trax/ogf/print/templates
stylesheet: this is the style sheet which will be used for the generated results. The available style sheets can be seen in the print-xml properties file. Examples are report.html and report.csv.
customizer: Optional customization can be done here. A java class has to be written in order to use these customizations. As value, they have the customizer setting (between xml and customizer) from the print-xml properties file. For example custom will stand for xml.custom.customizer. the configured parameter will thus be customizer set as custom

Print-XML Properties File

format.date=dd/MM/yyyy format.datetime=dd/MM/yyyy HH\:mm\:ss format.bigdecimal.maxscale=2

xsl.AccountStatement.AccountStatement.template=com/trax/accountstatement/print/Ac- countStatement.html.xsl xml.AccountStatement.AccountStatement.customizer=com.trax.accountstatement.print.Ac- countStatementXmlCustomizer

xml.AccountStatement.AccountStatement.depth=4 xsl.Payment.Envelope.template=com/trax/payment/print/Envelope.html.xsl xml.Payment.Envelope.customizer=com.trax.payment.print.EnvelopeXmlCustomizer xml.Payment.Envelope.depth=4 report.html=com/trax/ogf/print/templates/report.html.xsl report.csv=com/trax/ogf/print/templates/report.csv.xsl custom.report=com/trax/template/print/report.html.xsl xml.custom.customizer=com.trax.template.print.CustomCustomizer

To change the images for the generated file, modify the resources in application.properties file. resources.url=http://localhost:8081/webstart. The logo itself is a png file in the webstart.war

Impact on Performance

Both of these reports use the same parameters and are based on the generate report rule. Since generation takes place on the server, performance of the entire application would suffer if large queries were performed. For this reason, a default limit of 20.000 data rows & fields has been implemented. This means that the total of number of rows x number of fields per row may not exceed 20.000. A counter will track the number of resulting data fields which have to be returned and display a warning if the result exceeds the size. The “report-limit” parameter can be set in the application.properties file. If no value is set, the default of report-limit = 20000 will be supposed.

Every query is also a database connection so care must be taken that not too many connections happen in parallel as the amount of possible connections is limited by a setting in the application.properties file.

Views

A database view is a query stored in a database. This query can be accessed as a virtual database table. The view changes as the database changes.

Currently, several views are provided

Account Statement Balance
Intraday Balance
All Payments present in the system
Account Statement details

Payments View

Trax payments contain information that can be present on envelope level or on payment level. The purpose of this view is to show a list of all individual payments present in the system with all the desired fields filled out, even if these field values are not present on the payment itself but on one of the envelopes.

This view converts the currency of the payment to the defaulted exchange rate category currency using the most recent exchange rates present in the system.

The main Trax table of this query is the payments table. In this way, all payments present in the system will be retained by the view.

It should be noted that, after the introduction of transformation objects, payments can be retained twice as both their original entity as their copy will be present in the view. Users of the view should take this into account when deriving aggregated information from this view.

Debtor Account

The debtor account should be retained from the static data model. If a payment has not been enriched yet, these fields will be empty.

Number
Code
Name
Currency

Debtor Bank

The debtor bank is the bank attached to the debtor account retained from the static data model.

Code
Name
BIC
National Clearing Code

Debtor

The debtor is the holder attached to the debtor account retained from the static data model.

Code
Name
Country

Payment

The payment is the main object of this view. All payments present in the system are retained.

Requested execution date
Creation date
Own reference
Counterparty reference
Batch reference

Repository

The repository is the status in which the payment resides.

Code
Description
Workflow indication (BP for bulk payment and UP for unitary payment)

Amounts

Two amounts are retained. The first amount is the original amount of the payment. The second amount is the original amount converted to the currency of the defaulted exchange rate category. The exchange rate applied is the most recent exchange rate present in the system for the original currency. Only one default exchange rate category may exist. Otherwise, for each payment, an additional record will be retrieved for each additional defaulted exchange rate category.

If the currency of the original amount equals the currency of the defaulted exchange rate category currency, the original amount and the original currency is used to fill out the converted amount and the converted currency fields.

When no exchange rate is defined for a particular currency, the converted currency will be equal to the original currency. In this way, the converted currency column can be used by a user to check which currencies were converted by the query and for which currencies the query was not able to convert that currency. As a consequence, the converted amount will also not be converted and remain equal to the original amount.

Original instructed amount
Original instructed amount currency
Converted instructed amount
Converted instructed currency

Data owner

The data owner is the legal entity owning the payment.

Code
Name
Description

Beneficiary

The beneficiary is the counterparty of the payment.

Beneficiary account number
Beneficiary account currency
Beneficiary account bank BIC
Beneficiary account bank NCC
Beneficiary account bank Name
Beneficiary name
Beneficiary country

Signing

If the payment has already been signed by one or more users, the view shows the user who has last signed the payment (or its envelope).

Name

Account Statements View

The purpose of this view is to show the three balances present in the system for each account present in the static data model. Date stamps are provided for each balance so that a user can easily derive a particular balance on a particular date for a particular account.

The sum of the total debit and credit movement of each account statement forms the net amount of that account statement.

The accounts table in the static data model is the main table of this view. In this way, all accounts present in the static data model are retained, even if the system does not contain any account statements for a particular account.

Intraday statements are not taken into account in this view.

It should be noted that summations are present in this view. Therefore, only account statements are present being a member of one of the following inventories:

AS_ARCHIVED_NOT_PUBLISHED
AS_ARCHIVED_PUBLISHED
AS_NOT_PUBLISHED
AS_PUBLISHED
AS_VALID
AS_READYTOSEND

Account

The account information is retained from the static data model:

Code
Name
Account Number
Account Currency

Holder

The account holder:

Name
Country

Bank

The bank of the account:

Country
Name

Type

The account type:

Name

Data Owner

The data owner is the legal entity owning the account:

Name

Balances

The following balances are retained:

Opening balance
Closing balance
Closing available balance

For each balance, the following fields are present:

Amount
Currency
Date

Amounts

The following three amounts are present:

Total debit amount of the account statement
Total credit amount of the account statement
Net amount of the account statement, summing the total (negative) debit and the total credit amounts.

Intraday Account Statements View

Whereas the previous view contains all the closing balances present in the system, this view only shows the most recent closing balance for each account present in the static data model.

Additionally, the view contains an overview of the intraday account statements received after the most recent closing balance date present in the system. In this way, a user will be able to retrieve the most recent account balance.

The account movements of the intraday statements are summated. For this reason, the view assumes that the received intraday account statements are non-cumulative. When cumulative intraday account statements are received, the view will still work correctly if only one intraday account statement is received between the last two closing balances.

The actual balance of an account is computed by summating the following items:

The most recent closing balance date present in the system.
The account movements of all intraday account statement movements having a posting date more recent than the most recent closing balance date.

Only account statements will be present that were validated by Trax. More concrete, only account statements are present being a member of one of the following inventories.

Account Statements:

AS_ARCHIVED_NOT_PUBLISHED
AS_ARCHIVED_PUBLISHED
AS_NOT_PUBLISHED
AS_PUBLISHED
AS_VALID
AS_READYTOSEND

Intraday Account Statements:

ID_ARCHIVED_NOT_PUBLISHED
ID_ARCHIVED_PUBLISHED
ID_NOT_PUBLISHED
ID_PUBLISHED
ID_VALID
ID_READYTOSEND

Account

The account information is retained from the static data model.

Code
Name
Account Number
Account Currency

Holder

The account holder

Name
Country

Bank

The bank of the account

Country
Name

Type

The account type

Name

Data Owner

The data owner is the legal entity owning the account

Name

Balances

The closing balance with the most recent date is retained

For this balance, the following fields are present:

Amount
Currency
Date

Amounts

The following amounts are present:

Total of debit/credit movements of all retained intraday account statements
Total balance: sum of this total and the closing balance

Additionally, a currency is provided for these two balances. The date field contains the most recent entry date of the movements on the intraday account statements.

Account Statement Transaction View

The purpose of the view is to display all the information associated with a particular transaction on the account statement. The attributes required for the account statement detail view are listed.

Data Owner Static Data Account

The data owner is the legal entity owning the account

Code
Name

Account

The account information is retained from the static data model.

Code
Name
Account Number
Account Currency

Holder

The account holder

Name
Country

Bank

The bank of the account

Country
Name

Type

The account type

Name

Account Statement Number

Account Statement Detail Date

Value Date
Entry Date

Account Statement Detail Amounts

Currency
Signed Amount
Debit/Credit Indicator

Account Counterparty

Identifier

Account Statement Detail References

for Account Holder
for Account Servicing Institution

Account Statement Detail Information

Message Zone
Supplementary Detail
Rejection Code
Related Document

Account Statement Detail Transaction type

Code
Description
Sub Code
Heading Code
Sub Code Type

Account Statement Detail Internal Transaction type

Detail of Transaction

Configuration

Importing into the Database

Use an SQL application such as TOAD or Squirrel SQL (http://squirrel-sql.sourceforge.net/)) to upload the views into the database. In order to do so, start the application, connect to the data- base, select the scripts and execute them.

Using in BIRT

In BIRT, Let your SQL statement use the views by using something along the lines of SELECT * FROM VIEW_AS_BAL or VIEW_ID_BAL or VIEW_PAY_TXS.

Rule Engine

Introduction

The rule engine consists of three levels of interaction. A rule library, a rule sequence and custom rules. The rule configuration settings are by default located under the System menu of the navigation.

A rule sequence consists of a number of consecutive rules and the parameters which are to be passed to those rules. The rules themselves have to be defined first or they can be selected from a list of available rules (depending on implementation).

Rule

A rule consists of general information and rule parameters. The general information is described below.

{width="3.259258530183727in" height="2.115495406824147in"}

Field Contents Type

Name Name for the rule 140 chars Description Description of the rule 255 chars Implementation class Full classname, the java implementation for this rule 255 chars Locked Once a rule has been locked, it is impossible to modify or change the rule parameters. Rules which are used in a default AvantGard Trax implementation and do not have to be modified later on (e.g. specifying an output directory must also be possible later on) will be locked to prevent accidental erasure or modifications. Take care with this feature as once a rule has been created and locked, it is not possible to modify this self-created rule anymore either. The only recourse is to delete the entire rule and rewrite it. The rule cannot be unlocked. T/F Input Class GUI class which will provide the input for the rule. 255 chars Output Class GUI class which will handle the output of the rule. 255 chars

The Rule parameters are listed under the rule parameters tab and can be edited, added or deleted as necessary (unless the rule has been locked).

{width="4.111111111111111in" height="2.6329593175853017in"}

The parameter details are configured in the detail screen shown below.

{width="4.329492563429572in" height="2.160715223097113in"}

Field Contents Type

Name Name of the parameter 140 chars Data Type The parameter type Selection Class Name The class of custom created code. This is a technical reference to a JAVA component and reserved for custom integration. 255 chars Type The parameter type Selection Description Description of the rule parameter 255 chars Required Set to true if this parameter is required T/F Default Value Default value for the parameter. 255 chars

Rule Sequence

A rule sequence contains a number of rules which are sequentially executed. The previously configured rules form the building blocks of a sequence. The sequence contains both general information and the rule invocations.

NOTE: When parameters of a rule sequence are removed, it is recommended to restart the server.

{width="4.141850393700787in" height="4.163310367454068in"}

Field Contents Type

Code Code of the rule sequence. 40 chars

Name Name of the rule sequence. 128 chars

Description Description of the rule sequence. 255 chars

Disable Audit When rules are executed by the system, it is not always necessary to keep these in the logging history. When the check box next to disable audit is checked, modifications by the system are not logged for audit purposes. T/F

Disable Change Approval When rules are executed by the system on objects to which change approval applies, it would be inconvenient to approve every modification by hand. When the check box next to disable change approval is checked, modifications by the system are always considered valid and do not have to be approved. Note that if Audit is disabled, change approval must be disabled as well. T/F

Invoke On Collection Identifies if the input should be treated as a collection. Every item is processed separately, even when multiple have been selected. T/F

Elements

Global Transaction En- abled If a collection is used as input, processing for all elements will be done in one transaction. For example, when multiple items are selected for processing together and processing fails while not all items are processed, the result will be reported as failed for all. T/F

Transaction Enabled Enables a transaction around the sequence. All actions are performed for a single item. T/F

The Rules which are invoked are listed in the Rule Invocation section of the screen.

For each of these rules, the details can be requested. In these details, the sequence number has to be chosen and the rule itself has to be selected from a list.

It is considered good practice to use multiples of ten to set the sequence. That way rules can be inserted between the currently listed later on.

{width="3.1792443132108485in" height="2.518700787401575in"}

It is possible to pass a parameter to the selected rule. The passed parameters are listed under rule invocation parameter. They can be edited, added or removed here as well.

The passed parameter details are displayed in the screen shown below. The rule parameter itself is selected from a list and the value which it should pass can be entered in the value field.

{width="3.5892858705161856in" height="1.2484481627296589in"}

Actions

An action can perform a rule. The rule is assigned to the action in the rule field.

{width="3.731382327209099in" height="3.4415660542432196in"}

Field Contents

Translations can be added, edited or deleted under the Action Translation tab. The buttons for the corresponding actions are located to the right.

{width="3.7395713035870517in" height="3.107143482064742in"}

Streaming

Introduction

As of AvantGard Trax release 4.2 the streaming framework provides a new approach to processing input files. The framework is designed to ensure a small memory footprint while still being able to handle large files.

Another feature of the framework is the ability to process transaction-level I/O Pack structures and JAXB objects in parallel. This will yield better throughput results on multi-core platforms. The thread pool configurations can be customized via AvantGard Trax application properties.

All AvantGard Trax server platforms support these new features.

Validation Configuration

The Format Definition entity of the AvantGard Trax Message model is extended to support extra configuration for the streaming framework. This configuration is more verbose than it was for the classic approach. This is because each I/O Pack format level or streamed XML element is processed separately to ensure low memory usage.

{width="3.921259842519685in" height="2.6968503937007875in"}

This complexity is encapsulated in a Format Definition entity and is reflected in the GUI configuration of a format.

Classes that map the input to the AvantGard Trax model and back operate on a single level only.

The implemented validations are also more complex to configure, but this complexity comes with greater flexibility as well.

In the classic approach, validations were defined in the I/O Pack structure XML definition and were linked in during the build. This meant that all validations were statically added and if changes were required within a custom AvantGard Trax implementation, it was necessary to create a custom build of the AvantGard Trax format.

One of the benefits of the streaming approach is that the activation of validations is no longer static. The supplied validations can be activated or deactivated and custom validations can be added to the format definition via the GUI.

{width="4.122047244094488in" height="2.8858267716535435in"}

A streaming approach - by its very nature - does not support in-memory collections of child entities. This implies e.g. that an Envelope object has no access to its collection of Payment objects. A java.util.Iterator implementation is provided on supported top-level value objects to retrieve persisted child value objects in batches. The batch size of this iterator can be specified globally via an AvantGard Trax application property.

However, for streaming cross field validations, it is no longer possible to iterate through such a collection. Instead, an event mechanism is introduced to support communication between the different format levels.

For example, implementing a validation that checks for total fields checksums is no longer performed by iterating through the collection of payments and counting the amounts, but by sending events with amount information from the payment levels to the higher envelope levels.

Please note that both a streaming and classic implementation of an AvantGard Trax format can coexist.

However, it involves 2 implementations of the mappers and validations, and a subclass of the top-level structure must be created in which the non-streaming validators are statically added to the respective structure classes. As soon as this subclass is loaded, it is no longer possible to use the streaming approach in the same VM, because validations will produce incorrect results.

{width="4.149606299212598in" height="2.8858267716535435in"}

Aside from the necessary syntax-specific validations that the I/O Pack requires to parse and interpret the input data, all validations can be activated and customized separately. These validations are typically referred to as "Cx" and "Dx" validations.

The screen shown in Fig. 12.3 “Overall Validation Configuration” presents an overview of this configuration.

{width="2.6037292213473315in" height="1.2125207786526684in"}

When a validation configuration is selected, the reported error code, error level and description can be modified separately as shown in “Figure 9‑4 Configuration of a single validation”.

When a specific format definition is loaded, it is used by the streaming framework to generate code at runtime, which is then cached for subsequent requests.

Please note that modifications to the Format Definition entities of already loaded formats require a restart of the server-side AvantGard Trax application to be reflected in this generated code.

XML-Specific Level Configuration

By default, child elements are written to the output stream at the XML event "beforeEnd" of the parent element.

E.g. in case of pain.001.001.02, all payments of a batch (XML elements <CdtTrfTxInf/>) are written to the output stream before the end tag of the batch is written (XML element </ PmtInf>).

If the format requires another position for the child elements, the XML Specific Level Configuration tab can be used to customize this intercepting behavior. This is e.g. the case for the batches (XML elements <PmtInf/>) of a format envelope (XML element </Document>), that have to be written before the end of XML element </pain.001.001.2>.

The XML Specific Level configuration contains two input fields. One text field "ElementName", which contains the wrapper element to intercept and a drop-down list "InterceptWriterPosi- tion", which contains the position to intercept (beforeEnd, afterEnd, afterStart, beforeStart).

Validation Results

When validating a format with the streaming framework, each validation error will be collected and enriched with functional information such as the Path and will be provided in the server log. This path represents the level and sequence of the respective structure in a dot-notation. For example "1.1.3.2" should be interpreted as follows: first file envelope, first format envelope, third batch envelope, second payment. If you want to see which payment is invalid, the sequence column can be added to the view.

Rollback/Commit Behavior

Because the streaming framework is designed to handle large files, regular JTA transactions cannot be used. Using regular transactions would cause transaction timeouts and memory issues.

To achieve data integrity, the concept of "long" transactions is introduced. This is a lock-based mechanism that allows intermediary commits to the database. The lock is enforced by the security manager to shield these objects from access until the lock is removed. Only the internal users can access these temporary objects.

The difference between a regular JTA transaction and a "long" transaction, is that data is committed to the database with an insert lock code ('I-<XXX>', where XXX is a unique trans- action identifier). A rollback is simulated by setting the lock code field to the value 'D' (mark for deletion). A scheduled job is provided to purge these marked value objects, and can be configured to run at specific times.

A commit is simulated by removing the insert lock of the affected value objects. As soon as this update is committed, the changes become visible for other users that would normally be able to see those value objects (data owner).

If the application server crashes, or the database server becomes unreachable during the run of a long transaction, the already persisted objects remain in the database. This is stale data.

Periodically the SYS-CleanupDatabase job checks for entities older than a configurable period with an insert lock code. If such entities are found they are removed from the system.

Based on the error level of the encountered validation errors, a decision is made to rollback or commit the changes.

This is done as follows:

If the collector contains no events, the resulting value objects will be committed and the related communication object will move to the processed state.
If the collector contains only warning-level events, the resulting value objects will be committed , but all encountered validation warnings will be added as processing history to the top-level value object and as communication history to the related communication object. The communication object will move to the processed state.
If the collector contains error-level events, the resulting value objects will be rolled back, the related communication object will move to the failed state, and any encountered validation errors will be added as communication history to this communication object.

Please note that long transactions only support new value objects (changes to existing data cannot be rolled back).

Application Properties

# 1. Thread pool configuration

#

# The streaming framework uses different thread pools to perform its tasks in parallel.

#

# They all have the same properties.

# - core.pool.size: minimum number of threads in the thread pool

# - max.pool.size: maximum number of threads in the thread pool

# - queue.size: queue capacity to store requests until a worker thread in the pool gets a chance to process it

# - executor.keep.alive.time: time in milliseconds to keep idle threads alive

# 1.1. Processing thread pool

#

# This thread pool is used to process JAXB objects and I/O Pack structures as soon as they have been parsed.

#

#executor.core.pool.size = 1

#executor.max.pool.size = 5

#executor.queue.size = 5

#executor.keep.alive.time=300

# 1.2. Read thread pool

#

# This thread pool is used to parse input and create corresponding Java objects.

#

#read.core.pool.size = 1

#read.max.pool.size = 5

#read.queue.size = 5

#read.keep.alive.time=300

# 1.3. Batch persistence thread pool

#

# This thread pool is used to persist batches of value objects in parallel.

# It is only applicable if the persistence mode is set to 'batch'.

#

#persist.core.pool.size = 1

#persist.max.pool.size = 1

#persist.queue.size = 5

#persist.keep.alive.time=300

# 1.4. Write thread pool

#

# This thread pool is used to convert structure and JAXB objects into character data and write output.

#

#write.core.pool.size = 1

#write.max.pool.size = 5

#write.queue.size = 5

#write.keep.alive.time=300

# 2. Persistence manager configuration

# 2.1. Persistence mode (can be either 'batch' or 'default')

#persistence.manager.mode=batch

#2.2. If in batch mode, specifies the batch size of value objects to persist (applies only to lowest streamed levels)

#persistence.manager.batch.size=250

# 2.3. If in batch mode, specifies the time in milliseconds that the persistence manager will wait before interrupting a final flush

#persistence.manager.wait.time = 300000

# 3. Properties for the runtime-generated Spring application contexts for streaming formats.

# 3.1. Buffer directory that is used to store temporary data on disk.

#file.handle.buffer.directory=/tmp/handle-buffer

# 3.2. Format error collector size. Specifies the maximum number of warnings/errors to col- lect. Default value is 0 (unlimited).

#errorcollector.warning.size=0

# 3.3. Queue size for the pull streamer. This queue is shared between the read thread and the processing threads.

#streaming.queue.size=25

# 3.4. Batch size for value object iterator (used for streaming persisted value objects from the database)

#streaming.batch.size=250

# 3.5. Schema cache directory where XSD files are extracted and stored temporarily on disk.

#schema.cache.directory=/tmp/xsd-cache

Streaming Integration

Introduction

The format error report is generated when uploading a format file which contains errors and/or warnings.

Errors cannot be handled by I/O Pack readers and will always result in a database rollback for the file that contained the errors. No value objects will be persisted in the database for a file that contains errors.

Warnings do not result in reader failure, but are a result of checks performed, e.g. syntax validations, checksums or text patterns.

The configuration described here works for both the streaming and the classic format implementations.

Interaction between Streaming and Validations

In the classic approach, validations were hardcoded. This meant that all validations were statically added and if changes were required within a custom AvantGard Trax implementation, it was necessary to create a custom version of the AvantGard Trax format. In the streaming approach, this is no longer necessary. The supplied validations can be activated or deactivated and custom validations can be added to the format definition via the GUI.

When reading data in either streaming or non-streaming mode, there are four possible outcomes:

Valid: everything is correct
Error category: an error occurred when reading the data.
Warning category: a validation has failed.
Unexpected category: Any problem not covered by the other outcomes.

Classic (Non-Streaming) Handling

Standard validation will be TRUE by default.

Read errors will result in an error level
Validation errors will result in a warning level
custom validations will result in a warning level.

Streaming Handling

Standard validation are all reading errors
Format XML validation is always on
Via the GUI, other validations can be (de)activated
When “Fail on warning” is activated, every warning will be handled as if it was an Error level.

Compared to the classic handling:

Read errors will result in an error level
Validation errors will result in a warning level
Custom validations will result in a customizable level.

When an error occurs, the communication will have failed and there will be no business object (envelope) available. The error will be written to file as parameter. When a warning occurs, the communication object will be ok and the envelope will have been persisted.

Writing

When data is written, it will always be subject to strict validations.

I/O Pack errors and exceptions

To accomplish this for the classic formats, a refactoring of the I/O Pack errors and exceptions was needed.

The following exceptions were removed:

com.trax.iopack.validation.exception.ReadException
com.trax.iopack.api.xml.SyntaxException
com.trax.iopack.validation.error.Error
com.trax.iopack.validation.error.ReadError
com.trax.iopack.validation.exception.CompareException
com.trax.iopack.validation.exception.DomainValidationException
com.trax.iopack.validation.exception.ExpectedSyntaxMissingException
com.trax.iopack.validation.exception.FieldFormatException
com.trax.iopack.validation.exception.GarbageAtEndOfFileException
com.trax.iopack.validation.exception.GarbageBeforeConditionException
com.trax.iopack.validation.exception.NoReadableQualifiesException
com.trax.iopack.validation.exception.RequiredBlockMissingException
com.trax.iopack.validation.exception.SizeSplitException
com.trax.iopack.validation.exception.SizeValidationException
com.trax.iopack.validation.exception.StartOfBlockMissingException
com.trax.iopack.validation.exception.StructureValidationException
com.trax.iopack.validation.exception.ValidationExceptionSet
com.trax.iopack.validation.exception.WrongLineLengthException

In favor of the new com.trax.iopack.validation.exception.FormatException.

This FormatException contains one or more FormatError(s):

{width="2.3854166666666665in" height="3.5208333333333335in"}

The following error interface, implementation and obsolete collector were removed as well:

com.trax.iopack.validation.error.Error.java
com.trax.iopack.validation.error.ReadError.java
com.trax.iopack.validation.error.ValidationErrorCollector

For backwards compatibility with existing formats the following Exceptions & Error have been deprecated (but are never thrown), will be removed.

com.trax.iopack.validation.exception.TraxValidationException
com.trax.iopack.validation.exception.ValidationException
com.trax.iopack.validation.error.ValidationError

Custom I/O Pack formats

No changes to existing format validators and mappers are needed but it is strongly recommended to remove the use of deprecated classes & methods, because they will be removed in next AvantGard Trax releases.

Please note that custom I/O Pack formats will have to be regenerated, only source code compatibility is tested.

Applying business logic when reading streaming formats

This only applies to streaming formats that are mapped to the Payment model.

It is possible to apply additional business logic when loading streaming formats into Trax by piggybacking on the streaming principles of the I/O Pack framework.

There are two ways to inject additional business logic:

By implementing the PaymentLogic interface as a plain Java class
By implementing a Groovy script that returns a PaymentLogic implementation

These implementations can be activated by adding the load-logic parameter to the desired format definition and listing either the fully qualified Java class name or the code of a System.Script value object as its value. In case of a script reference, the code must be prefixed by “script=”. The script must be present in the database and must be of type Groovy.

Multiple implementations can be combined as a comma-separated list and both plain Java implementations and Groovy script references can be mixed. They are executed in order of appearance.

An example of a Groovy implementation – conveniently called PaymentLogicSample – is available in the Sample data-set for your reference.

Thread safety

It is important to understand that a single instance of a PaymentLogic implementation is used to process all levels of the mapped value objects, meaning that all envelopes and payments are passed through this single instance. This is in contrast to the streaming mappers and validators/notifiers of which a new instance is created for each individual envelope and payment.

This implies that instance data is accessed by different threads and all read and write operations must made thread-safe by either using proper synchronization or other techniques such as the atomic classes or collections in the java.util.concurrent package.

If a class takes care of its own thread safety, the class or all of its implemented methods must be annotated with the @PaymentLogic.ThreadSafe annotation.

If a class or its methods are not annotated with the above annotation, a reflective proxy is created to externally synchronize all method calls. This has an impact on performance and hinders parallelism, so it is recommended to think about proper thread safety yourself.

Data Sealing

Principle

AvantGard Trax can protect access to data by using passwords and authentication, but a data- base administrator might still access the database itself where the data is vulnerable to changes. To counter this threat, AvantGard Trax offers data sealing. When this feature is active, changes made to the database by AvantGard Trax are characterized by a signature generated by the application. In this way, it is possible to detect changes which have been made by other sources than the AvantGard Trax application server.

Data sealing also makes use of digital signatures to address potential issues resulting from the application of the four eyes principle. A message can be sitting for some time in the database before actually being sent, e.g. waiting for the proper authorizations to be issued. Therefore care must be taken that a database administrator cannot modify this data in the interval, e.g. to deviate some funds to his private bank account.

When data is saved to the database, a digital signature is generated using a private key that is managed at the level of the application, and is unknown to the technical staff having access to the database. This allows AvantGard Trax to verify, before sending the message, that all information remains as it was when authorized.

FAQ

Where is the sensitive information stored?

In the database.

Is an attempt of data modification directly in the database detected?

Yes, all information which is considered sensitive is protected by a data seal. This applies to both data flows and static data. This can be customized to include other data fields as well.

Where and how is the private key stored?

By default the key is stored inside the application ear file, optionally it can be stored on a secondary protected directory on the file system. The key is contained in a serialized (encrypted) javax.crypto.SecretKey file. A default key is delivered together with the product. This key can be replaced by a key generated specifically for each install. (The generate tool is included in the framework). In this way you can ensure complete confidentiality (including from SunGard staff).

How is expiration handled?

There is no automatic key expiration. If desired a new private key can be generated and installed at any time. When a new key is installed the old key is effectively revoked as it cannot be used anymore for existing or new data.

What happens in case the key gets lost?

No secondary recovery key exists, if the primary key is destroyed it should be recovered from backup or a new one generated. A backup of the private key should also be done in a separate location then the database. When restoring both elements (database & key) should be restored together.

What happens if somebody tries to create a new message directly in the database?

This message will not be accepted and will trigger a data seal alert. An application log event is triggered TRAX-SEC-00410. All alerting options (for example email) are available.

What can be done in case the on-site security is breached and the database is tampered with?

Both privileged delete and database repair can be used to bring the database back in service.

Implementation

The implementation of the technique in AvantGard Trax is based on digital signatures. AvantGard Trax is capable of generating a digital signature for an object and storing that signature at database level. Every manipulation of that object is subject to a validation of the digital signature. Every update of the object by the application server will generate a signature that is consistent with the data in the object. For this purpose, a key is contained in the AvantGard Trax enterprise application archive (ear).

Any attempt to modify data that is secured in this way at the level of the database, will be detected by AvantGard Trax during subsequent processing. AvantGard Trax will raise a "Security Breach" exception, displayed to the end-user if the action was invoked by means of the user interface, and logged if the action was invoked by the scheduler. The action will fail in its entirety, consistent with the transaction boundaries of the context in which the action is executed.

The entities that are subject to data sealing can be customized. By default, an example integration of sealing functionality will be provided. For a list of available entities, see System > Entity configuration as System User in AvantGard Trax.

Note that this type of configuration is part of the implementation process. That is, the AvantGard Trax system does not provide a graphical user interface for this purpose and this function cannot be activated at a later time, it must be set up during the development phase

It is possible to create a custom 3DES encryption key by the client after implementation and installation so that complete confidentiality is guaranteed. A script which executes Encryption helper can be provided for this purpose. Do note that all user passwords will have to be reset and all data seals have to be recalculated and stored in the database. This can only be done when the application itself is not currently in use.

Visibility

Data sealing is done by AvantGard Trax in the background and as such invisible to the user. The only location where the sealing mechanism is visible is in the database. There, the records will contain a field showing the sealing. Any tampering with the sealing in the database will be noticed by the application.

{width="5.239583333333333in" height="1.124128390201225in"}

Recovery from Tampering

The situation of a security breach is expected to be rare. Therefore, the recovery is not integrated in the daily workflow and processing logic. In order to recover from such a situation, two alternatives are provided: privileged delete or database repair.

Database Repair

A database repair tool which will correct all inconsistent signatures in a AvantGard Trax data- base can be provided. Note that the separation of the database administrator role and access to the database repair tool is crucial in the support of a secured setup as otherwise the database administrator would be able to tamper with the data and then correct the seals to cover the tampering. The same applies to the database administrator role and access to the AvantGard Trax enterprise application archive, since this application contains the key used for generating signatures.

The tool is called repairSeals.bat and comes delivered as a compressed file with all libraries and configuration files as required. Some customization of the configuration files can be done in order to control batch size of records per sealed entity to repair (batch) and logging level of the tool (silent true/false). The configuration files are located in the config folder.

batch=100

silent=false

In case the system account has an invalid seal, it is necessary to disable sealing, run the repairseals tool and re-enable sealing again.

repairSeals.bat

The final line of the repairSeals command should contain the correct path to the JAVA virtual machine as used by the application server.

C:\WebSphere6\AppServer\java\bin\java com.trax.ogf.sealing.SealerRepairer

Application.Properties

AFTER you have run the repairSeals.bat to initiate the seals of the database, sealing can be enabled by making sure a seal-implementation-list property is available in the application properties file of Trax.

seal-implementation-list=com.trax.system.sealing.AllowedInventorySealer,com.trax.system.sealing.InventorySealer

Trax supports by default data sealing on below objects and fields:

AllowedInventorySealer

InventorySealer

SecurityProfileAuditSealer

SecurityProfileSealer

UserProfileAuditSealer

UserProfileSealer

UserAuditSealer

uniqueIdentifier\ code\ name

UserSealer

uniqueIdentifier\ code\ name

SignerProfileSealer

uniqueIdentifier\ all uniqueIdentifiers of signers

MandateSealer

code\ workflowID\ approvalType

accountGroupID\ accountID\ accountByDataOwnerID\ accountByHolderID\ accountByBankID\ paymentInstructionTypeGroupID\ messageInstructionTypeGroupID\ ICTGroupID\ CEVClassification\ signerProfile1ID\ signerProfile2ID\ maximumAmount\ minimumAmount\ maximumCounterValue\ maximumCounterValue\ minimumCounterValue\ maximumAmountCurrencyCode\ minimumAmountCurrencyCode\ checkOnTransactionLevel\ XPath\ description\ approvalState\ dataOwnerID

PaymentSealer

uniqueIdentifier\ orderingCustomerAccount/accountNumber\ counterpartyAccount/accountNumber\ interbankSettlementAmount/amount\ interbankSettlementAmount/currencyCode\ instructedAmount/amount\ instructedAmount/currencyCode\ valueDate\ requestedExecutionDate\ EnvelopeID\ repositoryID

EnvelopeSealer

uniqueIdentifier\ interbanksettlementAmount/amount\ interbanksettlementAmount/currencyCode\ counterValue/amount\ counterValue/currency\ valueDate\ requestedExecutionDate\ numberOfTransactions\ repositoryID

ArchiveSealer

archiveType\ uniqueIdentifier\ archiveDate\ exportDate\ businessDate\ ownReference\ E2EReference\ hash of archiveData

PasswordUpdator

AvantGard Trax protects access to users by using passwords and authentication, but someone can still gain access to the database and could try to tamper with the passwords to gain access of the system. In that case the actual user would not be able to login with his code and password and during the login the application would prompt error ‘Invalid login’.

How to update the user password in that case? There are two ways to update the user password:

Admin user can take ‘Set password’ or ‘Reset password’ actions to update the user password.
PasswordUpdator tool: This tool is packaged inside sealer package. To run the tool, the admin or support user needs to run passwordUpdator.bat (or sh file depending on the operating system). It will prompt for the user code and the new password of the user whose password needs to be updated. Also, this tool take care of password policy as it checks the password history of the user and other password checks. If the given password is present in the history it will not allow to update the password.

passwordUpdator.bat

The final line of the passwordUpdator command should contain the correct path to the JAVA virtual machine as used by the application server.

C:\WebSphere6\AppServer\java\bin\java com.trax.password.updator.PasswordUpdator

Application.properties

Old users created prior to TRAX version 5.7.1 are still able to login by making sure ‘use-old-password-algorithm=true’. By default this property is false under the application properties file of Trax.

User password algorithm

use-old-password-algorithm=false

Data Sealing on Communications

There is no seal check on the representation of a Communication or Message due to the possible performance impact in case of large content. This would impact user experience, since the seal gets calculated each time an object is retrieved from the database.

To solve this, the digest on the representation gets recalculated during transition from the incoming Communication trough the different states up to transmission to Swift. Tampering with the representation will be detected and reported back to Trax Payments. The seal repair tool will not work when the representation has been tampered with.

TSG receives a JMS message and creates a Communication and calculates the digest.
The job TSG-outbound-integrate will perform the ValidateTSGCommunicationRule on the incoming Communication digest and creates an outgoing Message.
The job TSG-outbound-transmission will perform the scheduleOutgoingGatewayCommunicationRule in wich he validates the outgoing Message digest and creates an outgoing Communication.
The job TSG-process-waiting-FileAct will perform the FileActProcessWaitingCommunicationRule in which he validates the outgoing Communication digest and send the representation to Swift.

In case the digest validation fails an Exception is thrown which results in a Failed status being sent back to Trax Payments.

Digital Signatures

Introduction

Signing administration allows AvantGard Trax to determine who is allowed to authorize payments, based on a number of criteria. It is possible to configure signing in the GUI so that the correct signing method, hardware and cyphers are used.

Do note that the device drivers for the supported hardware must be installed on the client machines and will not be distributed by SunGard for legal reasons.

Multiple tokens can be used by a single user, with possibly multiple certificates on each device. Vice versa, the same certificate can be assigned to multiple users, allowing them to physically share the same token.

The components below are supplied by default and should not be modified. If so desired, new methods and types can be created, but this can require coding.

What is a Signing Method?

A signing method combines the following four characteristics into a single easy-to-use set:

Approval type: Which type of authentication is required? None, PIN, token?
Key storage: Which token type is used?
Hash algorithm: How is the hash value calculated to represent the data?
Signing algorithm: How to create and verify a signature.

{width="2.6041666666666665in" height="1.84375in"}

The active flag is turned off for legacy signing methods, but can be activated if so desired within projects. Do note that when this flag is deactivated, it is not only impossible to use this signing method, but also any of the token administration functions. Unless no token is required, a signing method must have approval type, key storage, hash algorithm and signing algorithm filled out.

Which kinds of Approval Types are Supported?

An approval type is the means of authentication for signing and the following approval types are supported by default:

No authentication
Authentication (User needs to provide a password, could be internal DB password or LDAP or RADIUS password)
Challenge/Response (Strong authentication) via a token (User needs to provide token PIN) or key store file (User needs to provide key store file PIN)
Digital signature of specific fields via a token (User needs to provide token PIN) or key store file (User needs to provide key store file PIN)
Digital signature of the entire content via a token (User needs to provide token PIN) or key store file (User needs to provide key store file PIN)

{width="3.4479166666666665in" height="1.3020833333333333in"}

Which Tokens are Supported? (Key Storage)

The following tokens are supported:

SafeNet eToken PRO (72k Java)
SWIFT 3SKey token
Gemalto USB eSeal Token v3

{width="3.4479166666666665in" height="1.8020833333333333in"}

The following key storages are supported:

The private key stored in the database – PKCS8 key store (only for EBICS communications)
The private key (and its corresponding certificate) stored in the Windows registry of the local PC. AvantGard Trax accesses this private key using the Microsoft Cryptography API (MS-CAPI).
The private key (and its corresponding certificate) stored in a PKCS12/PFX key store file on disk of the local PC.

Which Signing Algorithm is Supported?

By default, the RSA public key cryptography algorithm is supported. The signing algorithm is used to create and verify the signatures and to initialize the token.

{width="3.4166666666666665in" height="1.3229166666666667in"}

Key Storage Configuration Options

PKCS12 Key Storage Options

PKCS12 key storage requires below parameters to be filled out:

path: the path of the PKCS12/PFX key store file on disk of the local PC. You can use below parameters:

{drive} makes the Trax signing applet scans multiple drives (that match the driveRegex parameter) for the key store file. This parameter is only allowed at the start of the path.
{user.home} makes the Trax signing applet use the user’s home directory on the local PC for constructing the key store file path. This parameter is only allowed at the start of the path.
When creating an EBICS digital signature, below list of parameters can also be used in the file name portion of the path:

{ebicsUser} gives the EBICS userID
{ebicsProfile} gives the Trax connection profile code
{ebicsBank} gives the Trax bank server code
{ebicsHostID} gives the EBICS bank server hostID
{ebicsCustomerID} gives the EBICS partner customerID
{ebicsSignatureVersion} gives A004, A005 or A006

driveRegex: regular expression for all drives that should match with the {drive} parameter. For example [A-Z]:\\ would match all drives from A:\ to Z:\
passwordLabel: the label to be used on the PKCS12 password dialog
driveLabel: the label to be used on the PKCS12 drive selection dialog

PKCS12 Password Prompting

{width="4.590551181102362in" height="2.7913385826771653in"}

By default, Trax will prompt for the password of the PKCS12 keystore file twice when using it for signing EBICS transmissions. This is because the PKCS12 is encrypted with a keystore file password that prevents Trax from reading its public certificates.

Note: this is in contrast to smartcards or cryptographic USB tokens where certficates are publicly readable without password.

As a system user, you can optionally add key storage parameter with name storePass on key storage PKCS12. The value you enter there is the shared PKCS12 keystore file password that will be used by the signing applet to open all PKCS12 keystore files to list the public certificates. The private key is still secured by a PIN that only the signer knows.

When using this for signing EBICS transmissions (i.e. signature methods PKCS12_EBICS_A004, PKCS12_EBICS_A005 or PKCS12_EBICS_\ A006), you also need to add parameter storePass on the EBI-EbicsExportSignatureKeyRule action with the same value as above.

Caution: this will make the resulting PKCS12 file non-standard (i.e. can no longer be read or imported by most 3rd party software) because the keystore file password and private key password are no longer the same

CMS (Cryptographic Message Syntax)

Digital signatures can be externalized if required by the counterparty. AvantGard Trax supports the CMS format for external digital signatures. The Cryptographic Message Syntax (CMS) is the IETF's standard for cryptographic protected messages. It can be used to digitally sign, digest, authenticate or encrypt any form of digital data.

To enable CMS output, check the External signature checkbox in an appropriate outgoing routing table. Please note that this setting is only useful if the signing method provides a digital signature.

{width="5.427655293088364in" height="3.4426312335958005in"}

Troubleshooting

Access Denied

If the system event viewer shows the following message: Smart Card Reader 'OMNIKEY CardMan 3821 0' rejected IOCTL GET_STATE: Access is denied, then the permissions have to be modified.

To do so,

open the registry editor (regedit)
go to HKEY_LOCAL_MACHINE\Software\Microsoft\Cryptography\Calais
set the permissions of the local service to “full control”

Signature Request is still in Password and not Token

Remember to log off and on again after performing modifications to the authorizations.

Device driver error

If the message “Device driver error, Please check your Java version and driver software” appears, then please verify that JAVA 7/8 32-bits has been installed client side and that the latest version of the token drivers is available on the client.

What is SWIFT Personal Digital Identity?

When interacting with corporate customers through electronic banking channels, financial institutions are sometimes required to authenticate received data (e.g. payment instructions) at the level of the individual (e.g. a specific representative in the corporate's treasury department). As a result, corporates and banks are often confronted with the complexity of multiple and different types of signing mechanisms (e.g. multiple tokens with different passwords), leading to higher operational risk and cost.

The need for authenticating (signing) messages at personal level has also emerged on SWIFTNet since corporates have started using SWIFT to interact with their banks (note that, since SWIFT's inception, users have exchanged messages authenticated at organization level, with SWIFT acting as a registration authority at BIC level). While initially restricted to a limited number of users/countries, this demand is now growing due to

stricter regulatory requirements
a larger corporate customer base and
new opportunities for dematerializing additional business flows (e.g. electronic Bank Account Mandates) which require personal authentication.

When initially discussing this requirement with the Corporate Access Group (CAG), it was felt that, given the multi-banking aspect of a potential solution, a cooperative approach was required which SWIFT could facilitate. As a result, an ad-hoc working group comprising CAG banks representatives was set up. The approach proposed in this document represents the outcome of the working group's findings.

Under the proposed approach, SWIFT will provide -through banks- PKI based credentials to corporates. Such credentials can be used by corporate representatives to sign data (e.g. payment instructions) sent to banks over any channel (e.g. Internet, SWIFTNet). The credentials would only become effective when registered (i.e. associated with the corporate representative) by each bank separately. For banks, such an approach caters for simplicity by avoiding any reliance between banks both in terms of registration process and usage of credentials (e.g. verification of credentials).

SWIFT provides (inactive) tokens to banks
Banks distribute these tokens to their corporate customers
Corporate representative activates the token by accessing the central SWIFT PKI infrastructure over Internet
The corporate representative registers with his bank via physical presence or secure remote ID technology to associate him with the unique identifier.

Trax Supports the Aladdin eToken PRO and Aladdin eToken NG-FLASH key for signing. SWIFT is launching the 3SKey (SWIFT Secure Signature Key) solution for a multi-banking environment.

For more information please refer to the SWIFT PDI documentation PDI token install and Digital ID solution description, available from SWIFT and provided with your tokens.

In order to install the tokes, please refer to http://www.swift.com/3skey/getting_started.html

To know more about 3SKey and the key algorithms used by SWIFT, please consult SWIFT collateral: See http://www.swift.com/3skey/index.html and select ‘Want to know more’… Note that passages in deep red are not applicable to SWIFT 3SKEY configuration.

Properties

Introduction

Application properties are a set of properties which determine part of the behavior of the server part of AvantGard Trax. Some parameters have default values which mean that when they are not set, the default behavior will be used. An example of this is cut-off, which is not active by default, but is active when the parameter is set. This means that cut-off=false is the default parameter, even when it is not set.

Application property values can contain up to 4000 characters.

Properties

Reporting

Parameter Example Value Purpose

reporting.datasource.jndi java:com.trax.hibernate.DataSource JNDI of the datasource used with BIRT reports resources.url http://localhost:8081/webstart URL for the images used in HTML printouts com.trax.system.userman- agement.SecurityIntercep- tor com.trax.reporting.ReportingSe- curityInterceptor Optional; Adds reporting security rules report-limit 20000 This counter will track the number of resulting data fields which have to be returned by a classic query builder ex- ecution and display a warning if the result exceeds the size. If no value is set, the default of report-limit = 20000 will be supposed.

File Upload

Parameter Example Value Purpose

fileupload-dir ../server/default/tmp Folder to store the uploaded files in fileupload-max-file-size 150000000 Maximum file size for uploaded files in bytes fileupload-temp-path ../server/default/tmp Temporary folder to store files during upload

Streaming

Parameter Example Value Purpose

file.handle.buffer.directory /tmp/handle-buffer Temporary directory for streaming file processing

EBICS

Parameter > Example Value > Purpose

com.trax.ebics.connector. EbicsConnector.traceDir > /tmp/trax-ebics-trace > It is possible to enable tracing of all EBICS XML data going over the wire. Tracing will be enabled when this property is set and disabled when commented out or not set. In this folder, the EBICS trace will be stored.

LDAP

The principle used by Trax to do LDAP authentication is the “double bind”.

Trax first binds one time with the LDAP server using a system user. Once this is done, Trax searches for the current Trax user, using the user’s “Code”. The LDAP attribute that has to match that code is configurable.

When the user is found, Trax will attempt a second bind with the LDAP, using the DN (distinguished name) of the user. The LDAP attribute where that DN can be found is also configurable.

LDAP properties should ideally be stored in the application.properties file. When LDAP is enabled, the security policy settings (password expiration, password minimal length, password maximum length) will be ignored. LDAP can be activated for logon and/or signing by configuring the appropriate user-authenicator and sign-authenticator property (see 12.2.8). A user can be authenticated against a backup LDAP server in case the primary LDAP server is not available. This can be achieved by providing a comma separated list of ldap provider ur’ls (ldap.provider.url).

Parameter Example Value Purpose

ldap.contextfactory com.sun.jndi.ldap.LdapCtxFactory LDAP context factory (do not change this value) ldap.provider.url ldap://ldapserver1:389,ldap://ldapsever2:389 Comma separated list of URL’s of the LDAP server ldap.logon.dn uid=admin,ou=system Distinguished name of the system user ldap.logon.password {3DES}QvVBowU/B1Y= Encrypted password of the system user ldap.search.dn ou=people,o=sevenSeas Place in the LDAP’s DN tree where to start the search ldap.filtering.attribute cn Name of the LDAP attribute that will be matched against the user code entered in AvantGard Trax. ldap.user.dn dn Name of the LDAP attribute where the user’s DN can be found (so it can be used for the second bind) ldap.ssl FALSE Set to true to enable SSL, false to disable SSL ldap.version 3 Version of the LDAP protocol

RADIUS

RADIUS properties should be stored in the application.properties file. When RADIUS is enabled, the security policy settings (password expiration, password minimal length, password maximum length) will be ignored. RADIUS can be activated for logon and/or signing by configuring the appropriate user-authenicator and sign-authenticator property (see 12.2.8). A user can be authenticated against a backup RADIUS server in case the primary RADIUS server is not available. This can be achieved by providing a comma separated list of radius hosts (radius.host).

Parameter Example Value Purpose

radius.host 192.168.0.1,192.168.0.2 Comma separated list of IP addresses of radius servers radius.secret shared-secret Shared secret between trax server and radius server radius.auth.port 1812 Port the radius server is listening on

Business Functions

cut-off FALSE Used to enable or disable cut-off

cev.enrichment.audit FALSE Enables CEV audit logging cev.trace FALSE Enables CEV detailed trace logging

Server Security

Parameter Example Value Purpose

security-manager com.trax.system.usermanage- ment.DefaultSecurityManager SecurityManager which will be used by AvantGard Trax

user-authenticator com.trax.system.usermanage- ment.InternalUserAuthenticator Authenticator that will be used by AvantGard Trax for logon authorization.

                                                                                   Possible values:

                                                                                   Internal db pwd (=default): com.trax.system.usermanage- ment.InternalUserAuthenticator

                                                                                   LDAP: com.trax.system.usermanage- ment.LDAPUserAuthenticator

                                                                                   RADIUS: com.trax.system.usermanage- ment.RadiusUserAuthenticator

Approve-authenticator com.trax.system.usermanage- ment.InternalUserAuthenticator Authenticator that will be used by AvantGard Trax for approval authorization (signing method=AUTHENTICATION).

                                                                                   Possible values:

                                                                                   Internal db pwd (=default): com.trax.system.usermanage- ment.InternalUserAuthenticator

                                                                                   LDAP: com.trax.system.usermanage- ment.LDAPUserAuthenticator

                                                                                   RADIUS: com.trax.system.usermanage- ment.RadiusSignAuthenticator

sign-authenticator com.trax.system.usermanage- ment.InternalUserAuthenticator Authenticator that will be used by AvantGard Trax for signing authorization (signing method=AUTHENTICATION).

                                                                                   Possible values:

                                                                                   Internal db pwd (=default): com.trax.system.usermanage- ment.InternalUserAuthenticator

                                                                                   LDAP: com.trax.system.usermanage- ment.LDAPUserAuthenticator

                                                                                   RADIUS: com.trax.system.usermanage- ment.RadiusSignAuthenticator

securityInterceptors com.trax.reporting.ReportingSecuri- tyInterceptor List of additional security interceptors (security rules that are added to the DefaultSecurityManager)

signing-manager com.trax.signingadmin.SigningMan- ager Signing manager implementation

General Server Configuration

Only Modify under exceptional circumstances

Parameter Example Value Purpose

SERVER_CONTROL_CLASS com.trax.template.startup.Start- Up,com.trax.service.ServiceServer- Control List of ServerControl implementation classes (executed at server startup and shutdown) propertiesProviders com.trax.system.properties.DBAp- plicationPropertiesProvider List of ApplicationProperties provider implementation application-logger com.trax.system.applicationlog.Ap- plicationLogHelper The used application logger. event-configuration-load-in- terval 600000 The application log configurations is cached for better performance. This means that when modifications have been made to application logging these changes are not processed until the cache is cleared. The following line determines how often the cache is cleared in milliseconds. If the parameter is not explicitly set, 10 minutes will be the time used by default. rule-library com.trax.system.rules.RuleLibrary Indicates the implementation of the RuleLibrary interface which helps executing an abstract rule sequence seal-flush-delay-seconds 30 Interval for saving invalid seals in number of seconds

Email Notifications

These settings are normally configured from within the GUI, but can also be set up in the application properties if so desired.

Parameter Example Value Purpose

notification-mail-server 10.254.202.5 In order for the mail notification to work, a correct mailserver configuration must be set up. This value determines the name/ip address of mail server. notification-mail-protocol smtp The mail protocol used for notification mails. This should always be set to SMTP unless a specific protocol has been developed for your implementation. notification-mail-port 25 The port of the mail server. Notification-mail-from-user [email protected] The from email address for outgoing mails. Note that this has to be filled out for mailing to work. notification-mail-user Trax optional. can be used to set the mail user when connecting to the server notification-mail-password MailserverPWD optional: can be used to send the password to the mail server com.trax.signingadmin.notification.body A {subject} is waiting for your approval Body of the mails sent for signing notifications, may contain placeholders. com.trax.signingadmin.notification.subject Signing Notification Subject of mails sent for signing notifications.

Transmission

Parameter Example Value Purpose

com.trax.alliancelite.emis- sion c:/Trax/Emissions/ Transmission directory, is usually set from within the GUI

File-Only Application Properties

The following application properties will always be read from file as they are incompatible with database storage.

audittrailhelper (for custom audit trail logging)
crudListeners (for custom CRUD listeners)
seal-implementation (for custom sealing)
seal-flush-delay-seconds
SERVER_CONTROL_CLASS
propertiesProviders
application-logger
rule-library
security-manager
user-authenticator
sign-authenticator
securityInterceptors
signing-manager

Example Application.Properties file

Header ################################################

              \#\#\#\#\#\#\#\#\#\#\#\#\# TRAX APPLICATION PROPERTIES \#\#\#\#\#\#\#\#\#\#\#\#\#\#

              \#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#

Reporting ### Database connection pool for BIRT Reporting reporting.datasource.jndi=java:com.trax.hibernate.DataSource

File ### Client file upload

Upload fileupload-temp-path=../server/default/tmp fileupload-max-file-size=150000000 fileupload-dir=../server/default/tmp

Streaming ### Streaming file processing

              \#file.handle.buffer.directory=/tmp/handle-buffer

              \#schema.cache.directory=/tmp/xsd-cache

EBICS ### EBICS trace files

              \#com.trax.ebics.connector.EbicsConnector.traceDir=/tmp/trax-ebics-trace

LDAP ### LDAP server parameters (only when LDAPUserAuthenticator is enabled)

              \#ldap.contextfactory=com.sun.jndi.ldap.LdapCtxFactory

              \#ldap.provider.url=ldap://localhost:389

              \#ldap.version=3

              \#ldap.ssl=false

              \#ldap.logon.dn=uid=admin,ou=system

              \#ldap.logon.password={3DES}QvVBowU/B1Y=

              \#ldap.search.dn=ou=people,o=sevenSeas

              \#ldap.filtering.attribute=cn

              \#ldap.user.dn=dn

RADIUS ### Radius parameters (only when RadiusUserAuthenticator or RadiusSignAuthenticator is enabled)

              \#radius.host=192.168.0.1

              \#radius.secret=shared-secret

              \#radius.auth.port=1812

prints ### URL for images and other resources used in html stylesheet (print/email)

              re[sources.url=h](http://localhost:8081/webstart)ttp://loca[lhost:8081/webstart](http://localhost:8081/webstart)

Customer ######################################################

Configuration ########DO NOT MODIFY BELOW LINE (business & security settings)########

              \#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#\#

              \#\#\# Enable / disable business functions

              cut-off=false

Professional ### Server security configuration

Services security-manager=com.trax.system.usermanagement.DefaultSecurityManager

              user-authenticator=com.trax.system.usermanagement.InternalUserAuthenticator

              sign-authenticator=com.trax.system.usermanagement.InternalUserAuthenticator securityInterceptors=com.trax.reporting.ReportingSecurityInterceptor

              signing-manager=com.trax.signingadmin.SigningManager

Do not modify ### Server general configuration SERVER_CONTROL_CLASS=com.trax.template.startup.StartUp,com.trax.service.Service- ServerControl propertiesProviders=com.trax.system.properties.DBApplicationPropertiesProvider application-logger=com.trax.system.applicationlog.ApplicationLogHelper

              event-configuration-load-interval=600000

              rule-library=com.trax.system.rules.RuleLibrary seal-flush-delay-seconds=30

Client Properties

Client properties are a set of properties which determine part of the behavior of the client part of AvantGard Trax.. Note that a server restart is required to show modified or added information.

Parameter Example Value Purpose

client.about.prop.server localhost Server name or location shown in the about screen (any client property starting with client.about.prop will be displayed alphabetically sorted in the about box)

blob.preview.size 50000 The size in bytes after which the previewed object is truncated. All bytes are available in AvantGard Trax, but not shown for performance reasons. The example is 50KB.

blob.upload.limit 100000000 Only files smaller than this size in bytes can be uploaded to the server.\ If the (GZip compressed) data is larger, an exception will be shown informing you of breaching the data threshold.\ The example is 100 MB.

blob.download.limit 100000000 Only files smaller than this size in bytes can be downloaded to your local machine.\ If the (GZip compressed) data is larger, an exception will be shown informing you of breaching the data threshold.\ All bytes are available in AvantGard Trax, but not downloadable for performance reasons.\ The example is 100 MB.

gui.swiftref-validation true This parameter determines whether BIC lookup, BIC validation and NCC lookup are enabled in the manual entry screens.

gui.environment UAT Optional environment show in right top bar of application and in the about box.

gui.help.url http://help.com Optional URL to a webpage with extra help information.

gui.message.info Welcome to trax Optional user message is show on logon page.

client.changePIN true Is the user allowed to change the PIN of his smartcard? (File menu)

client.changePassword true Is the user allowed to change his own password? (File menu)

client.changeUserProps true Is the user allowed to change his own properties? (File menu)

client.fileupload.dataOwner false Add a data owner selection box on the file upload dialog?

Message Upload Process (Classic)

Introduction

The message upload process takes a number of parameters designed to convert the financial format to an AvantGard Trax-suited model. The different formats and parameters are listed in the format annex and contained in Message > FormatFactory > Format Definition.

The general tab contains general format information. The other tabs are where an integrator can plug-in rules, classes or scripts to perform custom actions between each of the steps of a upload or write workflow.

Typical read and write rules will be removed of SWIFT header information or converting between single-line and multiline formatting with the help of carriage returns.

General

{width="5.383333333333334in" height="2.9270833333333335in"}

Field Required Content

Code Y a code that has to be unique for each format definition. The definition will be looked up using this code. Description N A description of the kind of format. Country Code recommended In the GUI, there is a menu bar. (Upload > Formats for...) A certain security profile configuration can have menu actions to upload certain formats. The country code will be used to locate the actions in that menu. Structure Y The IOpack Structure responsible for reading/writing/validating will be instantiated from this character sequence In Mapper recommended If you want to define the full upload process, you need to specify the input mapper in this field. In some cases the format definition can only be used to parse and validate with- out mapping to the model. Alternatively, maybe the format only needs to be used to write from a model to the format. Out Mapper recommended If you want to define the full write process, you need to specify the output mapper in this field. Again, as for the in- put mapper, only parsing and writing might be necessary or only reading to a AvantGard Trax model. Entity N To which entity of a model the format will be mapped. For informational purposes only.

Pre Read/In/Out Map and Write Strategy

The chosen type of strategy determines what has to be filled out.

When the type is Java, you need to specify the Java class that is going to do your custom action. Depending the tab you selected, your class should implement a certain interface:

Pre Read Strategy: com.trax.core.formats.StringProcessingInterface. In this class you have to implement the method String process(String). The input will be the file contents before parsing.
Pre In Map Strategy: com.trax.core.formats.StructureProcessingInterface. In this class you have to implement the method Structure process(Structure). The input will be the IOpack structure after parsing and right before mapping.
Pre Out Map Strategy: com.trax.core.formats.ValueObjectProcessingInterface. Now you have to implement the ValueObject process(ValueObject) method. The input will be a value object right before it is mapped. This is where usually conversion takes place.
Pre Write Strategy: com.trax.core.formats.StringProcessingInterface. In this class you have to implement the method String process(String), like with the Pre Read Strategy. However, in this you will have the character sequence generated after mapping and writing.

When the type is Script, you have to put a Groovy script in the Script tab. Depending on which strategy you are implementing, you will have other input. See the previous paragraph about the Java classes to know the input and output of your script.
When the type is Rule, you have to implement a rule sequence. Again the input and output depend on which strategy you are configuring.

{width="4.404349300087489in" height="2.849206036745407in"}

Rules

In the selected rule sequence, the load object step determines the used format with the rule invocation parameter “format”.

Account Validation

Introduction

This document provides an overview of the different account validations which are performed by AvantGard Trax. These validations are done with the ISO country model. For each ISO country, the BBAN and IBAN configurations are set in order to validate the ordering and counterparty accounts listed in the payment file (both on envelope/payment level). For more information about the IBAN syntax and structure, please refer to the Register of European account numbers as created by the European committee for banking standards (ECBS TR201 V3.9).

The ISO country information is located at ISO > ISO > Country and consists of the following elements:

Country Code
English and French name
IBAN properties
BBAN properties
SEPA properties

ABA Validation

ABA routing number validation is used when the following conditions are met:

National Clearing system is set to USABA
The National Clearing Code contains the ABA number
The country field of the validated party is equal to US

2 types of ABA validation are available:

Syntax validation (controlled by the ‘validate-aba’ parameter of the ValidatePaymentRule): if the 9-digit ABA routing number validation (Mod10(3*(digit1 +digit4 + digit7) + 7*(digit2 + digit5 + digit8) +digit3 + digit6 + digit9) = 0.) fails, the envelope is moved to the invalid repository.
ABA + validation (controlled by the ‘validate-aba-bic-plus’ parameter of the ValidatePaymentRule): checks if the ABA routing number is found in the SWIFTRef Bank Directory Plus directory using the National ID and ISO country code of this directory.

Validation in the Workflow

{width="4.89375in" height="3.7680555555555557in"}Validation is applied in the BP-Validate and UP-validate rule sequences (System > Rule Library> Rule Sequence). The first rule which is invoked in these rule sequence is the ValidatePaymentRule.

This rule functionally performs the following classification & validations

Account validations classify accounts into distinct types and validates them accordingly
BIC country complies with IBAN country. (ordering customer account & bank and counter- party account & bank)
BIC+ check: Checks if the BIC is found in the list provided by the SWIFTRef upload. This is done for the ordering customer account holder & bank, the counterparty holder & bank and the intermediary.
NCC check: Checks if the NCC is found in the list provided by the SWIFTRef upload. This is done for the ordering customer account bank the counterparty bank and the intermediary institution.
Validate format

The validate payment rule has following parameters

Name Description Required Default

additionalIbanValidation Does additional IBAN checks against the SWIFTRef directory if set to true. See (*) for more information. N false

checkBBANInIBAN Check the BBAN in IBAN. Uses country specific IBANProperty setting to define whether a BBAN algorithm should be called in the account validation N -

invalid-repository Repository to move to if validation fails Y -

overwrite-account- type If set to true and the account type is already filled out in the original information, it is over- written. Otherwise, the originally set type is kept. N true

preload-enabled > Enables pre-loading of additional characteristics and instruction codes if set to true > N > true

valid-repository > Repository to move to if validation succeeds. > Y > -

validate-aba > ABA routing code validation (mathematical equation with modulo10) > N > true

validate-aba- swiftref > Validates the ABA routing code against SWIFTRef directory > N > false

validate-bic > Validate the BIC > Y > -

validate-bic-country > Check the country of BIC and account > N > false

validate-bic-swiftref > Check the presence of BICs in the SWIFTRef directory > N > false

validate-ncc- swiftref > Check the presence of NCCs in the SWIFTRef directory\ > N > false See (**) for more information.

validate-countries > Checks that the country of the bank of the counterparty and of the ordering customer is filled in. > N > false

validate-format > Validate the format > Y > -

validate-oca > Validate ordering customer account? > N > true

(*) Additional IBAN Validation

Prerequisites are that the SWIFTRef directory is uploaded, otherwise, this validation will always fail.

The country code (first two characters of the IBAN) is extracted and the record with corresponding country code is retrieved from the SWIFTRef IBAN Structure. These in turn tell us where to find the national ID which is then extracted from the IBAN.

The following checks are executed:

Is the BIC of the bank present and if so:
National ID check: Does the national ID within the IBAN exist in the SWIFTRef directory. The purpose is to validate that the national ID contained by an IBAN is a valid national ID. Firstly the country code and the national ID need to be extracted from the IBAN by using the SWIFTRef IBAN structure record corresponding with the extracted country. Secondly, the SWIFTRef IBAN Plus directory needs to be queried by comparing the extracted country with the IBAN ISO country code of the SWIFTRef IBAN Plus and the extracted national ID with the National ID of the SWIFTRef IBAN Plus. If this query returns one or more rows, the national ID is valid.
BIC-IBAN combination: Does the BIC of the IBAN comply with the BIC of the bank? The purpose is to validate that the BIC and the IBAN belong to one and the same institution. This is done by comparing the 4 initial characters of the BIC of the bank with the 4 initial characters of the BIC from the SWIFTRef IBAN Plus directory which was looked up using IBAN ISO country code and the National ID extracted from the IBAN. If this comparison passes, the BIC-IBAN combination is valid.

Validation

Valid /invalid repository: End status of the payments, in function of the validation result:

If either Valid Content or Valid Format is 'Invalid', the payment is moved to the invalid repository
The valid content indicator depends on account and BIC STP indicators.
If all set STP states of the objects in scope are Valid, Unknown, or blank, the valid content Indicator is set to 'Valid'
Else, the valid content indicator is set to 'Invalid'

In case the validate-BICplus or validate BIC-country fails, the validate content indicator will also be set to 'Invalid'. Those validations don't have a STP state.

NCC Validation

Prerequisites are that the SWIFTRef directory is uploaded, otherwise, this validation will always fail.

In case the National Clearing Code is used in and it is not available in SWIFTRef the validation must fail.

The following checks are executed:

In case National Clearing System (NCS) is filled in, the ISO country codes are derived from the National Clearing System table (USABA is used in several countries). SWIFTRef is queried with those ISO countries and the NCC code. If the NCC code is not found in the SWIFTRef table the validation fails.
In case NCS is not filled in, the bank address country can be used instead. SWIFTRef contains all ISO countries while the NCS table only contains a limited list of countries.
In case NCS and bank country are both not filled in, SWIFTRef is queried only using the NCC. NCS and country are optional in XML, because having a country might not always be needed in context of a domestic payment.

Validation

Valid /invalid repository: End status of the payments, in function of the validation result:

If either Valid Content or Valid Format is 'Invalid', the payment is moved to the invalid repository
The valid content indicator depends on account and BIC & NCC STP indicators.
If all set STP states of the objects in scope are Valid, Unknown, or blank, the valid content Indicator is set to 'Valid'
Else, the valid content indicator is set to 'Invalid'

In case the validate-NCC-swiftref or validate BIC-country fails, the validate content indicator will also be set to 'Invalid'. Those validations don't have a STP state.

Developer Notes

Customizing Print Functionality

The xsl transformation done while printing an object uses the ResourceHelper for translations and other utility functions. The property "xsl.resourcehelper" in the application.properties file, can be used to provide a custom resource helper (must implement the com.trax.ogf.print.ResourceHelperInterface). The default value of this resource helper is “com.trax.ogf.print.ResourceHelper”

Templates

It is of importance to note that envelope templates are not supported. Only payment-level templates.

File Download Mechanism

See WebGUI documentation.

Setting the Internal Classification Type

The internal classification type to use should be configured via the incoming routing configuration.\ {width="5.020833333333333in" height="3.1666666666666665in"}

Memory size setting

The amount of memory reserved for AvantGard Trax can be set as parameter of the Java virtual machine. The startup script allows to set the parameters as described below.

Memory Size

XMS is the initial startup memory size, XMX is the maximum memory size. The verbose setting is used for logging. So the Java virtual machine starts with -Xms amount of memory for the heap (storing objects etc.) and can grow to a maximum of -Xmx amount of memory.

The amount of memory depends on the physical available memory and concurrent applications in the memory available memory, together with the requirements for AvantGard Trax (number of concurrent users amount of data processed,...)

Command:

set MEM_ARGS=-Xms256m -Xmx1024m -verbose:gc

Parameters:

Xms<size> set initial startup memory size (Java heap size)
Xmx<size> set maximum memory size (Java heap size)

Building an AvantGard Trax Application for JBOSS

If you want to build an application for JBoss, you need to take into account the following things.

Bob

Choose your project target to be "jbs".

Use ant targets like jbs-ear or jbs-dd.

Libraries

You need custom libraries for connecting with JBoss, use ${jbs-dir}/client/jbossall-client.jar.

Application.Properties

hibernate.properties:

hibernate.connection.datasource=java:OracleDS.– hibernate.transaction.factory.class=org.hibernate.transaction.JTATransactionFactory

hibernate.transaction.manager_lookup_class=org.hibernate.transaction.JBossTransactionManagerLookup

application.properties:

java.naming.provider.url=jnp://localhost:1099

java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory

client-java.naming.provider.url=jnp://localhost:1099

client-java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory

Logging

Specify your log configuration using log4j.xml in the conf directory of your server configuration.

Client Start-up Parameters

-Djava.naming.provider.url=jnp://localhost:1099

-Djava.naming.factory.initial=org.jnp.interfaces.NamingContextFactory

Allowed Inventory Representation

Wizards take care of the allowed inventories, but the way this information is then stored in Trax is as follows:

#* -> where to look up the name of the column in order to display it
:1a -> sort on this column first, ascending (d for descending)
, -> separators to indicate a new sort/lookup instruction

CRLF & Scripts

The message workflow does not take scripts into account. In order to add extra carriage returns and linefeeds, use the set rule which exists in standard AvantGard Trax. The set rule takes a property and value as parameter and sets that property to the defined value. The property specifies the property of the object using the beanutil syntax and the value is the groovy expression to get the value.

For example, to add a linefeed to the trailer, the following set rule would be added:

property : trailer
value : context.trailer+”\r\n”

{width="4.75in" height="2.6125010936132984in"}

Trace and Timer Logging in Log4J

Currently two subsystems have trace and timer logging available to inspect the system performance:

com.trax.system.rules.RuleLibrary
com.trax.ogf.session.CRUDSessionBean

There are two types of logging available:

Trace logging (trace.*)

This log message (%m) will print "BEGIN" at the start of the execution and "END" when processing is complete.

Timer logging (timer.*)

This log message (%m) will print messages in the following structure "A;B;C", where:

A: Type of logged item: RuleSequence, Rule or CRUD
B: Name of logged item
C: duration in milliseconds

The following variables can be used for the log message:

%x Nested Diagnostic Context, function call stack with RuleSequence, Rule & CRUD

%X{SessionID} Session ID aka SecurityToken, containing the user & session start or internal for internal processes %X{RuleSequence} Currently executing RuleSequence (if any) %X{Rule} Currently executing Rule (if any)

The Template application contains the following setup which should be adjusted or disabled before putting in production as necessary.

</layout>

</appender>

<logger name="trace.com.trax.ogf.session.CRUDSessionBean" additivity="false"><level value="debug"/><ap-

pender-ref ref="trace"/></logger>

2010-02-16 13:04:05,072;main;(RSeq Server startup);BEGIN

2010-02-16 13:04:07,066;main;(RSeq Server startup) (CRUD FindByUniqueIdentifier);BEGIN

2010-02-16 13:04:07,202;main;(RSeq Server startup) (CRUD FindByUniqueIdentifier);END

2010-02-16 13:04:07,204;main;(RSeq Server startup) (CRUD FindByHQL);BEGIN

2010-02-16 13:04:07,318;main;(RSeq Server startup) (CRUD FindByHQL);END

2010-02-16 13:04:07,320;main;(RSeq Server startup) (CRUD FindByHQL);BEGIN

2010-02-16 13:04:07,485;main;(RSeq Server startup) (CRUD FindByHQL);END

2010-02-16 13:04:07,486;main;(RSeq Server startup) (CRUD FindByUniqueIdentifier);BEGIN

2010-02-16 13:04:07,487;main;(RSeq Server startup) (CRUD FindByUniqueIdentifier);END

2010-02-16 13:04:07,488;main;(RSeq Server startup) (CRUD FindByUniqueIdentifier);BEGIN

2010-02-16 13:04:07,488;main;(RSeq Server startup) (CRUD FindByUniqueIdentifier);END

2010-02-16 13:04:07,489;main;(RSeq Server startup) (Rule PurgeValueObjectsRule);BEGIN

2010-02-16 13:04:08,862;main;(RSeq Server startup) (Rule PurgeValueObjectsRule) (CRUD UpdateHQL);BEGIN

2010-02-16 13:04:09,502;main;(RSeq Server startup) (Rule PurgeValueObjectsRule) (CRUD UpdateHQL);END

2010-02-16 13:04:09,502;main;(RSeq Server startup) (Rule PurgeValueObjectsRule) (CRUD UpdateHQL);BEGIN

2010-02-16 13:04:09,844;main;(RSeq Server startup) (Rule PurgeValueObjectsRule) (CRUD UpdateHQL);END

</layout>

</appender>

2010-02-16 13:04:10,769;main;internal-2010-02-16T13:04:00;SYS-RecoverCommunications;SetCommunication- StateRule;Rule;SetCommunicationStateRule;120

2010-02-16 13:04:10,771;main;internal-2010-02-16T13:04:00;SYS-RecoverCommunications;;CRUD;FindByU- niqueIdentifier;1

2010-02-16 13:04:10,792;main;internal-2010-02-16T13:04:00;SYS-RecoverCommunications;;CRUD;FindByHQL;20

2010-02-16 13:04:10,811;main;internal-2010-02-16T13:04:00;SYS-RecoverCommunications;;CRUD;FindByHQL;18

2010-02-16 13:04:10,996;main;internal-2010-02-16T13:04:00;SYS-RecoverCommunications;persist;Rule;per- sist;184

2010-02-16 13:04:10,996;main;internal-2010-02-16T13:04:00;SYS-RecoverCommunications;;RuleSequence;SYS- RecoverCommunications;934

2010-02-16 13:04:10,996;main;internal-2010-02-16T13:04:00;Server startup;;Rule;ApplyRuleSequenceRule;1102

2010-02-16 13:04:10,996;main;internal-2010-02-16T13:04:00;Server startup;;RuleSequence;Server startup;5924

Set Repository

In release 4.4 the setrepository rule behaviour has undergone a major modification. prior to this version, it would set the repository of the top level envelope and on all child envelopes. As of this version, it will only set the repository of the top level envelope.

Please verify if this behaviour is appropriate if your bulk payment workflow has been custom- ized. To revert to the old behaviour the following method is available on payment envelope: public void setRepository(Repository repository, boolean recursive).

In addition the new rule SetEnvelopeRepositoryRule has been given a parameter to set the repository recursively.

Caching

As of version 5.7, Trax distributes cache changes via JM. Tne web and server layers are in sync in a single server and across multiple servers (e.g. batch, GUI, etc.).

The underlying cache framework is EHCache and is configured in the trax-ehcache.xml file (one for config-war and one for config-ear). This file contains the default settings for all implicitly created caches and some explicitly defined caches. Note that if a cache is defined explicitly in these configuration files and doesn’t specify a cache listener for incoming events, it does not participate in the distributed cache game.

All Trax cache managers connect to a JMS topic to notify others of specific cache changes and to receive information of remote cache changes. When a specific cache is cleared (i.c. when the removeAll method is invoked on the underlying EHCache instance), a JMS message is published on the topic that contains the name of the cache and the operation that has been performed. This message is then picked up by the peer caches and they clear their local version of that specific cache. All individual changes to the caches are not replicated to minimize overhead.

Currently all known caches are listed in cache.properties (included in the framework jar). This is needed to make sure that all caches exist on all environments so the necessary events can be triggered.

CRUD listeners react on changes in the persistence layer. The ValueObjectCache and DecoratorCache implementations cache all instances of a model entity and are automatically cleared by a CRUD listener when their related entity changes.

The topic that is used is available in JNDI at “java:/jms/TraxCacheTopic” and is accessed via the ActiveMQ resource adapter.

Here is a link on how EHCache uses JMS to replicate caches: http://ehcache.org/documentation/2.6/replication/jms-replicated-caching.

In a multiple server setup make sure that:

a single ActiveMQ server is installed
all application servers point to the same ActiveMQ server

Contract Linking with Bulk Files - Speed

The debulking configuration contains an entry to lookup the logical channel called com.trax.payment.rules.contract.ContractHelper.getLogicalChannel(). When this logical channel lookup is not required, it should be removed from the debulking configuration in order to speed up the debulking.

Multi-Byte Encoding

Multi-Byte Character Support

When files are not in the default ISO-8859-1 format which is converted by AvantGard Trax to UTF-8, they can be converted, depending on the format, to UTF-8 encoding by adding the parameter encoding=”XXX” with XXX being the encoding format to the reader rule of the load rule sequence. This has been verified for both the PAIN SCORE PAIN001 and Status Feedback PAIN002 format.

Common encodings include:

UTF-8
UTF-16
windows 1250
ISO-8859-1
KOI8-R

For more information about encoding types, please visit http://java.sun.com/j2se/1.5.0/docs/guide/intl/encoding.doc.html

Functionality includes the ability to import files containing multi byte characters into the Bulk payment workflow for processing and to then sending the payment file to the bank via SWIFT FileAct. The subsequent Status feedback messages can be received and processed through the Status Feedback workflow.

Once imported into the bulk payment workflow, end users will be able to view, sign, print and edit PAIN001 files. In addition end users can use the user interface filter to search within inventories using non-Latin characters e.g. Chinese characters. Also, end users will be able to view non-Latin characters that are present in the bank or holder information in static data and in the internal query builder.

Less-common CJK (Chinese/Japanese/Korean) characters are not supported due to their 4-byte length.

Oracle and UTF encoding

Oracle database scripts are by default not supported for usage with UTF with more than one byte per char. Database encoding should preferably be iso-latin1. In practice, this means that when an Oracle database is configured in UTF encoding some characters are presented by more than one byte. If you enter e.g. for a user the maximum length in code or name field with one of these characters a strange character, then the result is an SQLException that the string is longer than the maximum length defined for that field.

To resolve this, use the global database parameter: NLS_LENGTH_SEMANTICS = 'CHAR'. It can be modified without restarting the server with “alter system set nls_length_semantics=char;”

For more information please refer to:

Normally these menus are only available to the system user. To give this action to an end-user create 2 new actions with the following action classes.

Navigation: com.trax.system.usermanagement.gui.navigation.NavigationTreePanel
Menu: com.trax.system.usermanagement.gui.menu.MenuTreePanel

Add actions to menu, security profile...

Database Constraint Violation Messages

A subset of database constraint violation feedback messages shows the cause for this violation with a custom error message.The less common constraint violations that do not have their own message indicate that the referential integrity of the database has been violated.

In order to extend this subset additional constraints with their error message could be added in the StringTables.properties files available in webstart.war\ogf-gui.jar\com\trax\ogfgui\

SWIFT RAHA Connectivity Configuration (TSG Integration)

To use RAHA connectivity, the SWIFT RA software must be installed on the same machine where Trax is running and installed using the same user that runs the Trax application server.

The SWIFT RA environment must be initialized by calling a SWIFT initialization script in the application server startup script.

swiftnet init -S <RA_INSTANCE>

Note: <RA_INSTANCE> was defined during installation. The default is Ra1. This results in a number of environment variables being set.

SWNET_INST Ra1

SWNET_HOME C:\SWIFTAlliance\RA SWNET_BIN_PATH C:\SWIFTAlliance\RA\Ra1\bin SWNET_CFG_PATH C:\SWIFTAlliance\RA\Ra1\cfg SWNET_LOG_PATH C:\SWIFTAlliance\RA\Ra1\log

By default, Trax will use the default RA connection parameters (host name, port number, FTLA port number and SSL mode) that were entered during the installation of the SWIFT RA soft- ware. These default values can be found in <SWNET_CFG_PATH>\sagta_ra.cfg

Note: <SWNET_CFG_PATH> is set by the swiftnet init script. On Windows: C:\SWIFTAlliance\RA\<RA_INSTANCE>\cfg

On Solaris and AIX: /SWIFTAlliance/RA/<RA_INSTANCE>/cfg

HostName = 10.0.0.1

PortNumber = 48002

FtlaPortNumber = 48003

SSLMode = true

The 'Use SAG transport' option on the SAG connection will make sure that the values defined in Trax will be used instead of the default SWIFT RA values. (See the end-user guide chapter on SWIFT - FileAct).

If enabled, Trax will create a new SWIFT RA transport configuration file <SWNET_CFG_PATH>\sagta_ra_<TRAX_SAG_CONNECTION_CODE>.cfg

This file will contain the Trax defined values and will be referenced in the FileAct communication.

Additional SWIFT documentation can be obtained from SWIFT:

Alliance Gateway Remote API Installation Guide
Alliance Gateway Remote API Operations Guide

Time Zone Database Update

To update a java runtime environment (1.4+) with the last available time zone database, do the following:

Go to the Oracle website and download the TZ Updater tool: http://www.oracle.com/tech-network/java/javase/downloads/index-jsp-138363.html#timezone
Make sure that your JAVA_HOME environment variable is set correctly and "%JAVA_HOME%/bin" is included in the PATH environment variable
Unzip the archive
Run the updater tool (you might need administrator privileges, depending on your java installation): "java -jar tzupdater.jar -u -v"

More information can be found here: http://www.oracle.com/technetwork/java/javase/tzup- dater-readme-136440.html.

Adding Signers during Processing

In order to allow new signers to payments/envelopes already in processing, the stored list of allowed users must be updated by calling the SetAuthorizedUsersRule on the affected items. Alternatively, it is also possible to disable the filter which lets signers see only the items they are allowed to sign by removing the context=singning from the signing inventory or make a second "signing emergency" inventory. Note that removing the filter will come at the cost of performance. The signer will only be able to sign items to which he has the signing rights as these are checked from configuration during signing.

Maximum BLOB (Binary Large OBject) Size

In order to limit the memory size needed to display BLOBs, it is possible to set a maximum limit on both the BLOB preview size and the size of BLOB downloads. Both these are configured in the client properties of the system menu. These values are cached to improve performance. This cache will be cleared every hour to incorporate changes.

property Meaning Default

blob.preview.size The size in bytes after which the previewed object is truncated. All bytes are available in AvantGard Trax, but not shown for performance reasons. 5.000 (5Kbyte) blob.download.limit Data which is smaller than this size will be down- loaded to your local machine; If the (gzip compressed) data is larger, an exception will be shown informing you of breaching the data threshold. All bytes are available in AvantGard Trax, but not downloadable for performance reasons. 10.000 (10 Kbyte)

How to Create a Format Definition with CSV Output

Configuration

In order to create a format definition with CSV output, the engine class and format definition parameters must be defined. By default, an example format definition will be included in your copy of AvantGard Trax. CSV is only supported for account statement details and payments.

Constants are written by means of double quotes. If the CF_PF.properties file is appended with constant=”your value here” then the resulting CSV file will contain a final column containing the string: your value here.

Under Message > Format factory > Format definition, the example CSV_AS can be found. Let’s take a look at this in detail to see what is defined here:

Custom engine class = com.trax.message.formatfactory.SeparatedFormatFactoryEngine
The format definition parameters
DelimiterCharacter: The delimiter character is the character which is used in the CSV output file as separator between the columns. Make sure that you choose a value which is not included in your resulting data as this would result in inconsistent columns. It is possible to combine single characters to form a multi-character delimiter.
Mapping: The mapping configuration must be stored in the database as an application property. This property contains the different columns of the CSV file and a reference to determine which information is to be included for that column.
ValueObjectTransformer: this must be com.trax.payment.csv.extractor.EnvelopToPaymentTransformer (Notice the spelling of envelop, this is not a typo in this document) for Payments and com.trax.accountstatement.extractor.InternalClassificationTypeAccountStatementTransformer for account statement details.
DateFormat: The formatting used for dates. By default, this is dd/MM/yyyy but other combinations such as DD/mmm/YYYY are possible
AmountPrecision: The number of decimals which are carried over to the output. By default, four decimals will be used. If the number of decimals is larger than the amount precision, a rounding of the number will be performed, not a truncation.
IncludeHeader: If set to true, the header information is carried over as first line. If not, the top line will simply contain data like all the others. The header line equals all the values listed in the properties file on the left of the “=” mark. As such, the header name of a column is also defined in the properties file. As for the data, the column names should also be separated making use of the specified delimiter

Example

By default, the account statement example which is provided in AvantGard Trax has the following mapping. Note that this mapping always begins from the object transformer entity.

TransactionReferenceNumber=accountStatement/transactionReferenceNumber RelatedReference=accountStatement/relatedReference PrimaryIdentifier=accountStatement/account/primaryIdentifier/identifier StatementNumber=accountStatement/statementNumber SequenceNumber=accountStatement/sequenceNumber

ValueDate=valueDate

EntryDate=entryDate

DebitCreditMark=debitCreditMark/value

FundsCode=fundsCode SignedAmount=signedAmount TransactionType=transactionType/type

TransactionCode=transactionType/code

ReferenceForAccountHolder=referenceForAccountHolder AccountServicingInstitutionReference=accountServicingInstitutionReference SupplementaryDetails=supplementaryDetails CounterpartyPrimaryIdentifier=counterparty/primaryIdentifier CounterpartyName=counterparty/name

GLOffsetAccountCode=GLOffset/accountCode

GLOffsetLedgerCode=GLOffset/ledger/code

GLOffsetName=GLOffset/name

GLCashAccountCode=GLCash/accountCode

GLCashLedgerCode=GLCash/ledger/code

GLCashName=GLCash/name

InternalClassificationType=internalClassificationType/code

Currency=currency

Change Approval - Parent-Child Relations

When there are parent-child relations between the entities, change approval only has to be enabled for the parent entity, provided that the children cannot be directly accessed. This means that the change approval set for the security profile covers the changes which can be made to the children as well.

Suppose that change approval has to be enabled for the security profile. Each security profile has an allowed inventory and a set of security actions as children. Because it is impossible to modify what the actions do or what can be accessed by the inventories, it suffices to set change approval only for the security profile. It is the security profile which is modified and not the actions or inventories themselves.

It is not recommended to activate change approval on the child entities because it offers no added security and it complicates the process flow of change approval for the parent entity.

Browser Detection

The user sign-in page will forward to a webpage telling the user that his browser is unsupported based on the user-agent of his browser (unsupported.jsp). The user can nevertheless continue the login procedure to start AvantGard Trax. This warning for unsupported browsers is translatable (based on browser accept-language).

The regular expression responsible for the whitelist checking is configurable via client.properties. In the standard template release, IE8 and IE9 are supported.

unsupported.jsp does an extra check on IE8/IE9 compatibility view mode and will display an extra warning message in that specific case.

Rollback of Transactions

If the server crashes for whatever reason during processing, items which were being imported, have their status updated to lock code D which stands for Deletion. This is done so that no partially and possible corrupt data would become part of the database and endanger functionality and consistency. A periodically scheduled job will delete all data with lock code D.

Note that the job SYS_PurgeRolledbackLongTransaction must be scheduled to execute with a system user as profile as these “marked for deletion” records are only visible for system users.

Manual Entry MT101: Supporting Option 57D

In order to support option 57D in the manual entry MT101 screen, the 57A/57C validation must be removed. By default, either BIC or clearing code must be present. Option 57D does not offer either of these, but uses name and address to identify the counterparty bank.

Removing validation 57A/57C is done as follows:

Start the XGL editor by entering http://localhost:8081/editor/ in your browser
Provide your credentials to the system (username and password)
From the list of XGLscreens, select PaymentMT101
Look for validation
Remove the following part of the validation: evaluate(CounterpartyAccountBank_BIC:required = field.general.ownReference?required == true AND field.CounterpartyAccountBank_nationalClearing_code == null OR field.IntermediaryInstitution_BIC != null);
Look for validation  from the evaluate( CounterpartyAccountBank_BIC:required expression, remove the following part of the validation: field.general.ownReference?required == true AND field.CounterpartyAccountBank_nationalClearing_code == null OR

Resending Notifications

In order to resend/resubmit notifications, it is necessary to create an additional resubmit rule sequence as follows:

{width="3.08879593175853in" height="2.4871522309711285in"}

{width="4.565217629046369in" height="0.8977974628171479in"}

{width="2.7916666666666665in" height="1.6970614610673667in"}

Stacktrace Collecting

In the unlikely event that the application would keep the “working” icon (top right of the application) spinning without seeming results, it is possible to take a stacktrace on the server by opening the dos box where the application runs and typing CTRL+BREAK (kill -3 on unix). The resulting text should be copied (not with ctrl+c as this will stop the server) and can then be saved to file in order to edit it with a thread dump analyzer such as TDA.

Seal in filters

The seal attribute cannot be selected from trees, it can be used in the where clause of filters by means of expert mode.

Search Panels

Fields to be filtered upon can be added as a search panel (cfr below example) Note the specific ‘operators’ listed here:

EQ (equal)
NE (not equal)
GT (greater than)
LT (less than)
null (is null)

</fieldPanel>

</panel>

</xgl>

Functional Envelope Copy Rule

The Functional Envelope Copy feature allows the processing of the same envelope in more workflows and with the same data owners, with an intermediate end status for the original envelope. It can be triggered by any status in the UP and BP workflow. Once the original envelope has reached the status inventory, an exact copy of it is made and the cloned envelope is shown in a destination inventory, which is the starting point for new processing. The first data owner/user can still follow the new processing and view the original envelope into the end-status inventory.

During the copy:

All data that was available in the input file (functional data) is kept,
Unique own reference of the newly created envelopes and payments are generated
Data enriched during the enrichment phase, as Internal Classification Type, Data Owner, Confidential flag and Custom fields are kept,
While Number of Signatures, Processing History, the Representation, Approvals,...(processing data) are removed from the clone as compared to the original.

Moreover the clone will contain an entry in the Processing History, showing information about the database ID of the original file in the message: “This workflow object with {clone DBID} is a copy the workflow object with {original DBID} created at {datetime}.” There is no linking between the original envelope and its clone, neither via internal nor external Status Feedback.

The functional envelope copy rule (FunctionaEnvelopeCopyRule) makes a functional copy of the entire envelope. The clone is fully ready to be processed in a workflow. All technical and internal processing attributes are removed.

The functional envelope copy rule always expects a single Envelope or Payment value object as input which is why the “Invoke on Collection elements” option on the rule sequence must be turned on. This rule will only return the copy of the original and it has no rule parameters. All additional processing has to be done, leveraging other existing functionalities (e.g. setting the destination repository with the “setrepository” rule, generating a new Own Reference using the CEV framework).

{width="3.8956528871391076in" height="2.470784120734908in"}

Example of integrating the FunctionalEnvelopeCopyRule into the BP-release step of the BP workflow where within the ApplyRuleSequenceRule the “FunctionalEnvelopeCopy” rule sequence is called and afterwards the copy of the original envelope is re-directed to a new repository using the “setrepository” rule.

{width="4.694538495188102in" height="3.1478258967629045in"}

Example of integrating the FunctionalEnvelopeCopyRule into the UP-release step of the UP workflow.

{width="5.521738845144357in" height="3.7177515310586178in"}

Remove payment from envelope without being able to edit the payment or envelope

Payment envelope screens in AvantGard Trax can be configured to restrict operators, so that they can only remove (invalid) payments from an envelope, without being able to make any other changes (edit) to the payments and/or envelopes. The generic payment envelope screen (using the XGL ‘paymentField’ widget) allows flexibility with regards to which actions are allowed within the payment grid:

It is possible to configure which actions to show in the payment grid, with the ‘hideButtons’ attribute of the XGL ‘paymentField’ Macro.
It is possible to configure for the ‘edit’ and ‘remove’ actions, if these actions are allowed on all payments/envelopes or only on invalid (or duplicate) payments/envelopes shown within the payment grid, with the ‘editValidPayments’ attribute of the XGL ‘paymentField’ Macro.

By default, extra 'remove-payment-from-envelope' actions are included in the Bulk Payment rejected inventory and the Bulk Payment invalid inventory, which launch a generic payment envelope screen that only allows removal of payments and no edits.

Please note that when you remove the last payment from a (batch or format) envelope, this (batch or format) envelope will be automatically removed. When you remove the last payment from the file envelope, it will continue to go to invalid since Trax cannot handle empty envelopes. This behavior will continue to happen.

The "Remove" action is translated as "Reject payments", in order to be consistent with the fact that after "rejecting" the payment, the payment moves to the "manually rejected inventory".

Cleanup job

Periodically the SYS-CleanupDatabase job is executed. This job will

Unlock stale objects. Locked objects older than a configurable period will be unlocked. The period can be configured using the age parameter and can be expressed as a relative period (i.e. 2H, 3D, …).
Delete stale inserts. Objects that were inserted using a long transaction and are older than a configurable period will be deleted. The period can be configured using the age parameter and can be expressed as a relative period (i.e. 2H, 3D, …).
Delete marked objects. Objects marked for deletion will be deleted.
Fail communications. ‘initial’ and ‘incoming processing’ communications older than a configurable period will be set to failed. The period can be configured using the age parameter and can be expressed as a relative period (i.e. 2H, 3D, …).
Recover uncommitted published envelopes. Account statement envelopes that were created for publishing a number of statements using a long transaction and are older than a configurable period will be recovered. The statements will be put back in the workflow. The period can be configured using the age parameter and can be expressed as a relative period (i.e. 2H, 3D, …).

Use {variables} in the directory fields in Trax

In all “path fields”, I can define variables instead of a full path, e.g. {ap:FileServerPathRoot}/supplier/sap/…

The variable FileServerPathRoot then needs to be defined as a file application property

Permalinks with filter(s) on the inventory

Additional to navigating directly to an inventory (by adding the navigation path to the URL) parameters can be added to filter for values in that particular inventory. This is done by adding the parameter value pairs to the URL separated by slashes (/).

For example:

http://10.58.97.40:8080/trax/\#I\_UP-ManualEntry-MT101-UP\_PMT\_TEMPLATE\_MT101/templateCode/Intercompany

results in:

{width="5.405511811023622in" height="1.2086614173228347in"}

The parameter should be the property path as it is configured on the entity selection. However the parameters and values are already separated by slashes so the slashes in the property path should be replaced by dots.

In the example above a filter on “Target format” looks like:

http://10.58.97.40:8080/trax/\#I\_UP-ManualEntry-MT101-UP\_PMT\_TEMPLATE\_MT101/workflow.routing.targetFormat.code/MT101

which results in:

{width="4.947916666666667in" height="1.0in"}

Remarks

The filter is only applicable for String fields
Any previous filters on the inventories are cleared.
Several filters can be used. The two examples above combined looks like:

.../trax/#I_UP-ManualEntry-MT101-UP_PMT_TEMPLATE_MT101/

workflow.routing.targetFormat.code/MT101/templateCode/Intercompany

result:

{width="5.216535433070866in" height="0.8818897637795275in"}

Autostart

Function

The AvantGard Trax application server can provide automatic starting and stopping of services on server startup or shutdown. This can be used within projects to automatically start and stop services like FIN or FileAct

Components

Property SERVER_CONTROL_CLASS=com.trax.template.startup.StartUp in application.properties.

Rule sequence: Server startup

Rule sequence Server shutdown

Usage

Verify that the property SERVER_CONTROL_CLASS=com.trax.template.startup.StartUp is set in the application.properties file.

On the server go to server-jbs-localhost\server\default\deploy. (in accordance to your directory structure)
Open the template.ear archive
Select the folder \APP-INF\lib
Open the config-server-jbs.jar archive in that folder
Edit the file application.properties and verify the SERVER_CONTROL_CLASS line

In AvantGard Trax, edit the Server startup and server shutdown rule sequences.

Go to System > Rule Library > Rule Sequence.
Edit either the Server startup or Server shutdown rule
Select the Rule invocation tab
Add the rules which have to be executed on startup or shutdown.

Archiving

Archive extension

The archiving process can be extended with custom functionality to archive additional data.\ Implement com.trax.payment.archive.extension.sample.TransmissionArchiveExtension and activate it by setting the archive-extension application property in the application.properties file. Currently it is commented out and points to a sample extension (com.trax.payment.archive.extension.sample.TransmissionArchiveExtension) which archives the BLOB of the outgoing transmission and a BLOB containing the channel reference of the outgoing transmission to two separate archive data records, resulting in two extra files after the export.

Define final repository state

The ‘flag as to-be-archived’ step within the archive process can be customized for the UP and BP workflow (not for the AS workflow) by using the ‘repositories’ parameter of the UnitaryPaymentFlagArchiveRule (UP workflow) or BulkPaymentFlagArchiveRule (BP workflow rule).Using this ‘repositories’ parameter you can override the default final repositories using a comma separated list of repositories which should be considered by the ‘flag-archive’ job.

Archive custom workflow

Set up archive configuration

Create a new Archive configuration and link it to the custom workflow.

Implement com.trax.archive.archiveableworkflow

Implement the logic for flagging and mapping the custom workflow.

Example: com.trax.payment.archive.BPArchiveableWorkflow

Implement rules

Implement the rules for flagging, archiving, exporting and purging.

Examples: com.trax.payment.archive.BPFlagArchiveRule

com.trax.payment.archive.BPArchivePaymentRule

com.trax.payment.archive.BPArchiveExportRule

com.trax.payment.archive.BPPurgeArchiveRule

Configure rules, rule sequences and jobs

Create rules and rule sequences for flagging, archiving, exporting and purging.

Examples: BP-flag-payments-archive

BP-archive

BP-archive-export

BP-purge-archive

Schedule jobs for the rule sequences.

Examples: BP-flag-archive

BP-archive

BP-archive-export

BP-purge-archive

Adjust archive search panel

Edit the ArchivingArchiveSearch XGL screen and add the custom workflow to the comboBox. Create a new translation for internationalisation

Overview

{width="6.531944444444444in" height="3.2736111111111112in"}

Selective archiving

Introduction

Selective archiving has been introduced to offer more control on what gets archived. It offers the possibility to archive everything for a certain dataowner, regardless of the configuration for that particular workflow.

Selective archiving works for the unitary payments workflow (UP), the bulk payments workflow (BP), the message workflow (ME) and the account statement workflow (AS).

How it works

Selective archiving is controlled by configuring the same archiving jobs that already exist. Every workflow has four archiving rules (the index archive rule is left out of scope):

Flag for archive
Archive
Export the archive
Purge the archive

Those four rules have been given extra parameters, because selective archiving doesn’t use the archive configuration for the specific workflow.

Flag, archive and purge have two extra parameters, selective and dataowner. In addition, export has three more: exportBatchLimit, exportDirectory and exportSignature.

Once the selective parameter on the job is true, selective archiving is activated and replaces the ‘normal’ archiving via archiving configuration. Instead, all workflow objects belonging to the dataowner specified by the parameter will be processed.

selective A boolean to activate selective archiving

dataowner The dataowner code. All workflow objects having a dataowner with this code will be processed. Providing this parameter also triggers selective archiving exportDirectory The directory to which the archive records will be exported. Mandatory (and only used) for export. exportBatchLimit The maximum amount of archive records to be exported in one zip. Optional (and only used) for export. If not set, the default is 2500. exportSignature Indicates if the signature also should be exported. Optional (and only used) for export. If not set, the default is ‘false’.

Dynamic Code Lists

Introduction

Dynamic Code Lists in AvantGard Trax allow integrators and administrators to easily store and maintain customized code lists within the AvantGard Trax application. This is very useful when you have agreed upon a set of internally used, proprietary values that you want to display to users in the workflow screens. Furthermore, this feature also allows integrators to build XGL GUI screens in such a way that the custom code list is filtered, depending on the field value(s) in (an)other field(s).

Configuration

Creating a New Dynamic Code List

New Dynamic Code Lists always need to be created by the system user first, in order for other users (administrators with the ‘Application Data’ security profile) to start using/editing the newly created custom code list. Only a system user can add/delete a dynamic code list. A user with the ‘Application Data’ security profile can add/edit/remove list items to/from each of the available lists (navigate to Application Data > Lists > Code lists).

In order to create a new dynamic code list, log in to the AvantGard Trax platform as system/system, navigate to System > Gui > Code list and select the New action.

{width="4.98908573928259in" height="3.2959995625546807in"}

Field Required Description

Code Yes Unique identification of the dynamic code list, used by AvantGard Trax and stored in the database. Name No Meaningful name for the dynamic code list. Description No Meaningful description of the dynamic code list.

The ‘code list item’ tab, allows you to add/delete values to/from the newly created dynamic code list.

{width="5.0in" height="3.924623797025372in"}

Field Required Description

Code Yes Unique identification of the code list item, used by AvantGard Trax and stored in the database. Name No Meaningful name for the code list item. This name will be shown to users in the GUI dropdown. Description No Meaningful description of the code list item. Tag list No A comma separated list of tags, serving as meaningful categories to which the code list item belongs. The XGL GUI widget will on filter code list items by referring to such (a) tag(s). The tagging system is very flexible: tag names can be chosen in a completely arbitrary way and denote completely arbitrary dimensions, or they can reflect important values of some other code list in order to build in the necessary dependencies when working with the XGL GUI widget.

Lists (and therefore also list items) are audit-capable. This is disabled by default. When enabled, an inventory for pending code lists will become available in Application Data.

When developing custom payment entry screens, a new “configurable dropdown widget” can be used that takes its code list items from a dynamic code list and controls the content of a dropdown (that is offered to users in the AvantGard Trax GUI).

To enable the use of dynamic code lists in the AvantGard Trax GUI, a new native dataElement tag was added to XGL:

Name Type Required Description

list String Yes The code of an existing code list in AvantGard Trax to display in the GUI screen. useTags String No A comma separated list of tag values, used to filter the code list. Usage of multiple tags is supported, i.e. only list items that have all the corresponding tags will be available (in other words AND operator should be used between the tags).

The Name attribute of the code list item is used to display the items to the user. The Code attribute of the code list item is used in the data binding.

Furthermore, the “eval” event was extended with the extra attribute “useTags”. The eval event can be used to do generic logic in an XGL screen. The new useTags attribute allows you to dynamically change the displayed values of a dynamic code list in the GUI, depending on the values in one or more input fields (it is possible to use different input field types: combo-box, text field, etc).

Example Usage

Code List Creation

Let’s assume we want to create a customized code list in AvantGard Trax, defining all of the possible delivery methods for cheque instructions that are supported by all of the different banks we are doing business with. Once the dynamic code list is created by the system user, any administrator with the Application Data security profile, can edit the code list items in the dynamic code list. The tag list will reflect 2 dimensions in this example:

ISO or proprietary: this dimension will denote if the code list item is an officially supported ISO code (in which case it is tagged with the ‘ISO’ tag) or a customer-specific code (in which case it is tagged with the ‘proprietary’ tag). For example: the ‘22’ code list item is a proprietary code list item, which is not supported in the ISO external code lists, so it is tagged with the ‘proprietary’ tag.
Bank dimension: this will reflect the bank(s) that support the specific code list item. For example: the ‘MLDB’ code list item is supported by Citi, SCB and Nordea, so it is tagged with these tags.

Code Name Description Tag List

MLDB Mail to customer Cheque is to be sent through mail services to debtor. ISO,Citi,SCB,Nordea MLCD Mail to payee Cheque is to be sent through mail services to creditor. ISO,Citi,SCB,Nordea MLFA Mail To Final Agent Cheque is to be sent through mail services to creditor agent. ISO CRDB Courier to customer Cheque is to be sent through courier services to debtor. ISO,Citi,SCB CRCD Courier to payee Cheque is to be sent through courier services to creditor. ISO,Citi,SCB CRFA Courier to Beneficiary bank Cheque is to be sent through courier services to creditor agent. ISO,Citi PUDB Pickup by customer Cheque will be picked up by the debtor. ISO,Citi PUCD Pickup by payee Cheque will be picked up by the creditor. ISO,Citi PUFA Pick Up By Final Agent Cheque will be picked up by the creditor agent. ISO RGDB Registered mail to customer Cheque is to be sent through registered mail services to debtor. ISO,Citi RGCD Registered mail to payee Cheque is to be sent through registered mail services to creditor. ISO,Citi RGFA Registered Mail To Final Agent Cheque is to be sent through registered mail services to creditor agent. ISO 22 Courier 2 days to customer Courier 2 days to customer Proprietary,Citi 23 Courier 2 days to payee Courier 2 days to payee Proprietary,Citi 40 Print at location Print at location Proprietary,Citi,SCB,Nordea

{width="5.060869422572178in" height="3.344498031496063in"}

Implementing Dynamic Code Lists in the GUI

Let’s assume now, that we want to create code list dropdown in the AvantGard GUI screens, using the previously created dynamic code list with cheque delivery methods, that can dynamically change the allowed code list items depending on the values selected in 2 other fields: ‘Filter by type’, which will determine if it is an ISO or proprietary code, and ‘Filter by bank’, which will determine the specific bank.

<panel>

<data>

</data>

</comboBox>

<data>

</data>

</comboBox>

</comboBox>

</fieldPanel>

</panel>

</wgdialog>

</xgl>

{width="3.9270833333333335in" height="2.4791666666666665in"}

{width="3.9270833333333335in" height="2.5208333333333335in"}

{width="3.8958333333333335in" height="2.4583333333333335in"}

{width="3.9375in" height="4.208333333333333in"}

{width="3.9166666666666665in" height="2.5in"}

CEV

Custom building blocks

When writing a CEV building block which is a potential candidate for the next release of the product, take into account the following guidelines.

Create a rule sequence starting with CEV.
Use a groovy rule to implement the building block.
Use CEV naming conventions for the parameters of the building block, prefix them with the name of the building block. They can be accessed from params.

params.get("CEVAddInstructionCodeModifier.format")

JXPath parameters can also be used:

import org.apache.commons.jxpath.JXPathContext\ …\ String jxpath = params.get("CEVAddInstructionCodeModifier.jxpath")

JXPathContext jxPathContext = JXPathContext.newContext(context)

jxPathContext.setLenient(true)

Object value = jxPathContext.getValue(jxpath)

In case of a modifier

Add trace logging

params.get(“cev_logger”).trace("Add instruction code %s", code)

Invoke setModified

params.get(“cev_result”).setModified(true);

Add audit logging

params.get(“cev_logger”).audit("Add instruction code %s", "instructionCodes", "", code, code)

In case of a condition

Add trace logging

def logger = params.get("cev_logger")

logger.trace("Instructed amount: %s",

String.valueOf(instructedAmount))

logger.trace("High value minimum amount: %s", String.valueOf(highValueAmount))

invoke setValid

params.get(“cev_result”).setValid(valid)

Add logging when invalid

if (!isHighValue) {

logger.invalid("%s is too low", “instructedAmount”, String.valueOf(instructedAmount))

}

Example of a modifier

Name: CEVAddInstructionCodeModifier

Parameters: CEVAddInstructionCodeModifier.format\ CEVAddInstructionCodeModifier.code\ CEVAddInstructionCodeModifier.addInfo

if (context instanceof com.trax.payment.valueobject.Payment) {

def formatCode = params.get("CEVAddInstructionCodeModifier.format")

def code = params.get("CEVAddInstructionCodeModifier.code")

def addInfo = params.get("CEVAddInstructionCodeModifier.addInfo")

def format = com.trax.message.MessageHelper.getFormat(formatCode)

if (context.getInstructionCodes(format, code, null).empty) {

params.get("cev_logger").trace("Add instruction code %s", code)

context.addInstructionCode(format, code, addInfo)

params.get("cev_result").setModified(true)

params.get("cev_logger").audit("Add instruction code %s",

"instructionCodes", "", code, code)

}

return context

Example of a condition

Name: CEVHighValueCondition

if (context instanceof com.trax.payment.valueobject.Payment) {

def instructedAmount = context.instructedAmount.amount

def highValueAmount = com.trax.framework.util.ApplicationProperties

.getBigDecimal("UP-HighValueMinimumAmount", 0)

def logger = params.get("cev_logger")

logger.trace("Instructed amount: %s",

String.valueOf(instructedAmount))

logger.trace("High value minimum amount: %s", String.valueOf(highValueAmount))

def isHighValue = instructedAmount >= highValueAmount

params.get("cev_result").setValid(isHighValue)

if (!isHighValue) {

logger.invalid("%s is too low", "instructedAmount", String.valueOf(instructedAmount))

}

return context

Client/server validation

For manually created payments, a framework has been created to allow server-side validation before the payment is created. The goal of this kind of validation is to perform some basic checks on the payment before it gets persisted, and thus avoid that the payment will move to an invalid state later in the workflow.

How it works

Behind the XGL screens of all the format-specific payment screens, a new action is called when pressing the OK- or apply-button. This new action, called ‘PaymentPersist’, will call a rule sequence containing two rules: a groovy rule calling the script ‘PaymentValidation’ and the ‘WebPersist’ rule. It is the groovy rule that is responsible for the validations.

The groovy validation script

This is how the groovy script actually looks like:

{width="5.8in" height="4.65625in"}

At the beginning of the script a ClientValidationException is instantiated. In the middle part, the different validations are called. At the end, the ClientValidationException is checked to see if it contains any errors (size > 0). If so, the exception is thrown, the payment will not be persisted and the user will get the different validation errors in a message box on screen. If not, the context (the payment) will be returned and persisted.

Currently two validations are available in the product.

Validate requested execution date

The validation on the requested execution date has been added to give an example on how to add your own validations without writing any Java code.

As you can see in the script, first we check if the payment is an MT101. If so, we compare the requested execution date of the payment against the actual local date. If the requested execution date of the payment is more than 20 days in the future, handleWarning() method is called on the ClientPaymentValidator class.

There are two methods available on the ClientPaymentValidator class: handleWarning() and handleError(). Both take the same parameters as input:

An error code for which a corresponding translation is needed, prefixed with ‘error.’
The initiated ClientValidationException, which contains the list of validation errors
An optional java.util.List of parameters, needed to give extra information on the message to be translated

If the validation fails on the requested executed date, the user will be presented with a warning screen:

{width="3.0833333333333335in" height="1.28125in"}

The user has two possibilities: press the Yes-button or the No-button. If the user presses the Yes-button, he accepts the validation errors and forces the payment to be persisted. If he presses the No-button, the payment will not be persisted and the user will be returned to the specific payment screen.

Possible duplicate check

The possible duplicate check validation is comparable with the functional duplicate check in the workflow, but more lightweight: the list of criteria used during this duplicate check is smaller (for example data owner is not considered), ranges on dates and amounts cannot be used.

Similar to the functional duplicate check, it uses an application property called ‘manual.duplicate.validation.criteria’, which contains a comma-separated list of jxpath-criteria on the payment. These criteria are taken into consideration when the duplicate validation is performed. A hash is calculated based upon these criteria and is persisted on the payment when the payment is persisted. Be aware that this duplicate check only considers manually created payments, payments introduced in the system via another channel are ignored.

{width="4.208333333333333in" height="2.6666666666666665in"}

Important remark: When the list of criteria is changed, even if it’s only the order of the criteria, the hash of the existing payments will become obsolete because the calculation of the hash will be different, even if the payment contains the same data.

If the validation fails on the duplicate check, the user will be presented with a warning screen:

{width="3.125in" height="1.4479166666666667in"}

The user has now the same options as for the requested execution date.

Combining two or more validations

It is possible that the payment fails on two or more validations. In this case, the warning screen will show all validation errors and the user is presented with the same two options.

{width="3.1041666666666665in" height="1.8333333333333333in"}

When he presses the Yes-button, the user accepts all validation errors and the payment will be persisted. When he presses the No-button, the user will be redirected to the payment screen.

Mobile app configuration

List item fields

List item overview

{width="4.563136482939632in" height="1.6773173665791776in"}

Each displayable field in the mobile GUI has a default setup that will select values from the payments/envelopes in a hierarchical way: if the first property is empty, it will select the next one instead. All amounts and dates will be formatted according to the user’s regional settings.

Field Default values

                                      Payment

LargeField1 (e.g. SUNGARD US) Data owner code

                                      Ordering customer holder code

                                      Multiple ordering customer accounts

LargeField2 (e.g. ITP1) 1. Internal classification type

                                      2\. “Unitary payment” or “Bulk payment”

SmallField1 (e.g. REF: HWC/PAYM0001) 1. Counterparty reference

                                      2\. Own reference

                                      3\. “No reference” or “Multiple references”

SmallField2 (e.g. CHRIS P. BACON) 1. Counterparty name

                                      2\. Counterparty BIC

                                      3\. Counterparty holder NCS+NCC

                                      4\. Counterparty holder identifier+identifier type

SmallField3 (e.g. MainCompanyAccount) 1.Ordering customer code

AmountField 1. Instructed amount + instructed currency

                                      2\. Countervalue amount + countervalue currency

                                      3\. “No amount” (in the case of no exchange rate)

DateField 1. Cut-off time

                                      2\. Requested execution date

                                      3\. “No date” or “Multiple dates”

SignatureField 1. Given signatures (green) + required signatures (grey)

PaymentTypeField 1. Single note icon

Customizing list item fields

The administrator can change which payment/envelope properties are displayed when the defaults are unclear or unused. This can be done by setting the xpaths for the desired values in the “customfields.properties” file, found in “%PROJECT%/trax/trax-config/src/main/config-mobile”.

The fields can be altered individually and separately for payments and envelopes. This allows for a maximum of 16 custom property fields to be set.

For each property field, the administrator can select one or more (in a comma separated list) xpaths. In case of multiple xpaths, AvantGard Trax will try to get a value from the first one, and fall back to the next one until a value is returned.

In case no value is found, the administrator can select a translation to be shown in the field instead with the “translationKey” key. When setting up this translation in trax, note that the translation will be taken from the GUI translations. This means the translation must be prefixed by “gui.”, but this prefix must not be set in the “customFields.properties” file.

As a safety net in case the translation is not found, a hard-coded translation must also be set with the “translation” key.

When a field is not desired, it can also be removed by setting the “disabled” key to “true”. This will display nothing in the mobile GUI.

The amount field, date field, signature field and payment type field cannot be customized. Only largeField 1-2 and smallField 1-3 support this customization feature.

Below is an example configuration for setting the “LargeField1” field for envelopes to a custom value (for more information, see the explanation in the “customFields.properties” itself):

list.Payment.Envelope.largeField1.disabled=false\ list.Payment.Envelope.largeField1.xpath=orderingCustomerAccount/code\ list.Payment.Envelope.largeField1.translationKey=mobile.noData\ list.Payment.Envelope.largeField1.translation=No ordering cust code found!

Creating an iOS webclip

iOS allows the creation of a webclip, showing the web application full screen without browser header or footer bars.

To create a webclip, first browse to the web application in Safari and click the square with arrow icon (Figure 24-1) at the bottom. After the menu opens, choose ‘Add to home screen’ (Figure 24-2). Enter a name for the webclip and click ‘Add’ in the top-right corner (Figure 24-3). Now the web application can be launched like any other app from the homescreen (Figure 24-4). Described as it is done in iOS 7.

{width="1.8173906386701661in" height="3.223663604549431in"} {width="1.8260870516185477in" height="3.2391305774278214in"}

{width="1.8173611111111112in" height="3.223611111111111in"} {width="1.8292399387576552in" height="3.2447681539807522in"}

Mobile timeout

A separate timeout for the mobile connection can be set in the “Security policy”. This time-out is given in seconds and the default is set to “600”. After this time, the connection to the TRAX server is broken and the user has to sign in again to continue using the mobile signing interface.

{width="4.860869422572178in" height="2.6222134733158353in"}

Preface

Obtaining a License

Starting the Application

Importing Workflows

Importing Translations

Licensing keys

Prerequisites

</span></span></span>User Calculation

Users

Practical Example

Introduction

Practical Usage

Export

Exporting the Navigation

Exporting the Menu Structure

Export Location

Import

does not exist exists existing database records are kept

Change Approval interaction

Availability (Integrator)

Limitations

Export Location

Exportable.properties

Workflow

Bulk Payments

Enriched

Invalid Payments Algorithm

Manually rejected

Status Feedback Workflow

Prepare matching reference

Reconciling

Payment Screening

Indexes

Introduction

</span></span>Entity Selection

Determining the Columns to display

Determining the Column order

Choosing the Column Headers and their Translations

Choosing the Sorting for the Displayed Data

c d b Globally, 1st column a ascends to b to c

Special cases

Entity Configuration

Enabling Data Ownership

Enabling Audit

Enabling Change Approval

Actions

Creating a new Action

Changing the Translations for an Action

Menu

Adding an action/menu division to the menu

Modifying the menu structure

Inventories

Creating an Inventory and Filtering Data

Special Cases

Editing the list of Allowed Actions

Setting the Default Action for an Inventory

Changing the Translations of an Inventory

Adding a Counter to an Inventory

Adding Alerts to an Inventory

On Screen Filtering of Inventory Data

Refreshing Inventory Data

The Inventory Context

Navigation

Modifying the navigation structure

Adding an inventory/navigation element to the navigation

Custom URL

Addenda: The Counter Mechanism

Introduction

Triggers

Multi-Entity Adaptation

Performance

Decision Tables

Principle

Invocation

Rule Sequence

ApplyDecisionTableRule

Configuration of the Decision Table

Decision Table Properties

Decision Table Filters

General