Process Workflow
Process Workflow
Process Workflow
User Guide
No part of this document may be reproduced or transmitted in any form or by any means,
Electronic or mechanical, for any purpose, without the express written permission of TEMENOS Holdings NV.
Table of Contents
Overview .................................................................................................................................................. 3
Setup ....................................................................................................................................................... 4
AUTO.ID.START.................................................................................................................................. 4
LOCKING ............................................................................................................................................. 5
COMPANY ........................................................................................................................................... 6
PW.PARAMETER ................................................................................................................................ 7
Archiving ........................................................................................................................................... 7
PW.STATUS ...................................................................................................................................... 10
PW.PARTICIPANT ............................................................................................................................ 10
PW.TRANSITION .............................................................................................................................. 11
PW.MAPPING.................................................................................................................................... 15
PW.MAP.SOURCE ............................................................................................................................ 16
PW.ACTIVITY .................................................................................................................................... 17
EB.SERVICE ..................................................................................................................................... 19
ENQ SERVICE.LIST .......................................................................................................................... 19
PW.PROCESS................................................................................................................................... 21
PW.PROCESS.DEFINITION ............................................................................................................. 22
Enquiries ................................................................................................................................................ 24
Deal/Transaction processing ................................................................................................................. 27
PW.ACTIVITY.TXN ............................................................................................................................ 27
MAPPING .......................................................................................................................................... 28
@ID Mapping ..................................................................................................................................... 33
Automatic generation of records using OFS ...................................................................................... 34
The Process Workflow Setup: ........................................................................................................ 34
Auto Screen Presentation .............................................................................................................. 44
Auto process creation..................................................................................................................... 48
Data Mapping ..................................................................................................................................... 51
Local reference mapping ........................................................................................................ 57
Mathematical operators .......................................................................................................... 59
Application Program Interface ............................................................................................................... 61
Routines ............................................................................................................................................. 61
Literals................................................................................................................................................ 63
Reports .................................................................................................................................................. 64
Duration Analytics .............................................................................................................................. 64
Overview
T24 Process Workflow is aimed at grouping various businesses and banking procedures into a logical
process of activities. This grouping enables allocation of work to different users, ensuring vital tasks
are not left out causing a breakdown or delay in the process chain.
Individual activities are defined at micro level defining rules, statuses and user groups, which can all
be reused. These activities are then set out in a pre-defined sequence allowing a customized business
processed to be followed.
This module does not carry any business functionality but can be used to define and tune the flow of
business supported by other T24 modules.
Setup
AUTO.ID.START
AUTO.ID.START.
An AUTO.ID.START record must be set up for the PW.PROCESS and PW.ACTIVITY.TXN tables,
with an ID format of the following:
For PW.PROCESS table – ‘PW’YYJJJnnnnn. Where YY = Year, JJJ = Julian date and nnnnn =
sequence number.
For PW.ACTIVITY.TXN, the set-up is the same but for the prefix of ‘PA’. – ‘PA’YYJJJnnnnn.
Once the AUTO.ID.START record has been committed and authorised a LOCKING record will be
created for FBNK.PW.PROCESS and FBNK.PW.ACTIVITY.TXN containing the start Id’s for each file.
If these records are not set up correctly, when launching a new PW.PROCESS record in T24 Browser,
a blank screen will be displayed.
To correct this, reset the LOCKING records by correcting and recommitting the AUTO.ID.START
record for PW. The Cache file for Browser, F.OS.XML.CACHE, will also need to be cleared of all
records pertaining to PW.PROCESS.
LOCKING
LOCKING.
COMPANY
COMPANY.
The PW.PROCESS table (only) must be entered into the PGM.AUTOM.ID field on the COMPANY
record to enable automatic creation of ID’s.
PW.PARAMETER
Archiving
With the ever increasing transactions records in PW.PROCESS and PW.ACTIVITY.TXN the
configuration of PW.PARAMETER can utilised for archiving these records and moving them to
History.
PW.PARAMETER record.
The archiving process can either be done online using the TSA.SERVICE record
BNK/PW.PROCESSING or during the Close of Business using the BATCH process record
BNK/PW.PROCESSING.
Example
The current System Date is 30th Nov 2000.
As shown above the field MOV.HIS.DATE in PW.PARAMETER is defined as today’s system date.
The field COMPLETION.DATE in the PW.PROCESS record is set at 30th Nov 2000.
A shown below on running the TSA.SERVICE record BNK/PW.PROCESSING, the PW.PROCESS and
its related PW.ACTIVITY.TXN records are moved to history since they have reached the specified
COMPLETION.STATUS.
PW.STATUS
PW.STATUS.
Status codes are defined separately and attached to PW.ACTIVITY records. They are needed to
define the default status or starting status of an activity (DEF.STATUS.CODE on the PW.ACTIVITY
record) e.g. PENDING, and are also used to set the STATUS.CODES, in conjunction with a
STATUS.RULE, on the PW.ACTIVITY record when the conditions of the rule has been met.
PW.PARTICIPANT
PW.PARTICIPANT.
This table is used to group Users or Account Officers together and is attached to either the
PW.ACTIVITY or PW.PROCESS record. A User/Account Officer is then automatically allocated to
an Activity, spreading the workload systematically between all users/ Account Officers within the
PW.PARTICIPANT group.
This helps Users/Account Officers in identifying their daily work by using an Enquiry to drill down and
launch their specific tasks.
PW.TRANSITION
PW.TRANSITION is the table used to define conditions/transition rules. Transition rules are attached
to activities via the PW.ACTIVITY or the PW.PROCESS.DEFINITION table. These rules
determine when the status of an activity changes and the status further determines if and when a
subsequent activity can appear on the TO.DO list for a user and hence be executed.
When each multi-value is added from fields SELECTION.FIELD – CRITERIA, this acts as an ‘AND’
between the criteria – so if we have two multi-values, both conditions need to be met for the
PW.TRANSITION test to be passed.
The Selection Operand determines whether the above fields AND the below routine, or the above
fields OR the below routine, need to be satisfied in order for the PW.TRANSITION test to be passed.
PW.TRANSITION record.
Note: When both ROUTINE and SELECTION.FIELDS are given, the execution of the routine
specified in ROUTINE takes precedence over SELECTION.FIELDS rules.
When there is a value specified in the SELECTION.OPERAND field the ROUTINE field is mandatory.
When SELECTION.FIELD and ROUTINE are given without SELECTION.OPERAND then
SELECTION.OPERAND is defaulted to ‘OR’.
PGM.FILE record.
PW.TRANSITION.
There should be content specified for SELECTION.FIELD, ROUTINE or both. When ROUTINE is
given with SELECTION.OPERAND with no value in SELECTION.FIELD, the SELECTION.OPERAND
is defaulted to NULL.
When neither of the SELECTION.FIELD or the ROUTINE field is populated the SELECTION.FIELD
field becomes mandatory. But if ROUTINE is given SELECTION.FIELD is not mandatory.
PW.MAPPING
PW.MAPPING.
These records are used to map data from one activity record to another. The Mapping ID is attached
to the PW.ACTIVITY record where the data is to be mapped to. EG. If in a process a CUSTOMER
record is created, then an ACCOUNT record for that customer and you wish to map certain data from
the customer record to the account record, the PW.MAPPING record will be attached to the
PW.ACTIVITY for the account activity.
Please refer to the Data Mapping Worked Example for further information.
PW does not support mapping to the 2nd application/contract in a 2-phase application such as
mapping data from the main LD contract to LD.SCHEDULES fields.
PW currently does not support 2 phase commit applications with the exception of LD and
LD.SCHEDULES.
PW.MAP.SOURCE
PW.MAP.SOURCE.
This table can be used to define common field links to map data to be attached to the PW.MAPPING
table. This table allows data links to be re-used.
Please refer to the Data Mapping Worked Example for further information.
PW.ACTIVITY
PW.ACTIVITY.
These records determine the status, transition rules, duration, data mapping and so on of an activity.
The TARGET field defines which T24 application will be launched when the activity is executed; it
details how the application will be run i.e. how the application is usually executed from the command
line. PW currently does not support 2 phase commit applications with the exception of LD and
LD.SCHEDULES.
Please refer to the Data Mapping Worked Example for further information.
The field ALT.OWNER can be used to accept a hook routine only with a valid entry EB.API record.
On keying in any other value not already predefined in EB.API, an error message,” RECORD NOT
FOUND” will be shown.
This field enables distribution of an activity to a user in PW based on certain selection criteria (i.e., by
competence level or region). And, a user could be assigned to handle continuous activities (i.e., the
same user from the previous activity will be assigned to handle the next activity).
PW.ACTIVITY.
EB.SERVICE
EB.SERVICE record.
ENQ SERVICE.LIST
This enquiry record should display the service name, the activities associated with it and the target for
the activity (to be picked up from PW.ACTIVITY) in every row. This should accept a SERVICE.NAME
as selection criteria.
Enquiry SERVICE.LIST.
Enquiry results.
PW.PROCESS
PW.PROCESS.
The first step in setting up and starting a process is by creating a PW.PROCESS record. This
contains the PW.PROCESS.DEFINITION record that defines and determines the flow of activities
to be executed.
Once the PW.PROCESS record has been committed in Authorise mode, for each activity set up on
the PW.PROCESS.DEFINITION record that has no PRE.REQ.ACT attached to it, a
PW.ACTIVITY.TXN record will be automatically generated, thus only allowing activities to be
executed once previous tasks or activities have been performed. These PW.ACTIVITY.TXN record
IDs along with some detail are written to the PW.PROCESS record.
PW.PROCESS.DEFINITION
PW.PROCESS.DEFINITION.
This table allows the linking of activities together in a logical business flow. It defines when an activity
is enabled depending on pre-required Activities and their Statuses or Transition Rules. So
PW.PROCESS.DEFINITION helps not only in defining the activities to be a part of the process, but
the sequence and the stage at which they have to appear in the process.
Defining multiple status for process definition results allows activities to be completed based on
different sets of rules/conditions being met
PW.PROCESS.DEFINITION.
Enquiries
Launching of activities takes place through a drilldown ENQUIRY of the PW.ACTIVITY.TXN file,
allowing a user to automatically launch the activities from the enquiry.
The basic PROCESS.STATUS and TO.DO ENQUIRY records come as part of the T24 PW module.
Specified key words in these enquiries allow Process Workflow to function and care must be taken to
not delete or change vital fields in these basic ENQUIRY records.
See the below example of the important fields involved.
A FIELD.NAME field on the ENQUIRY record, as in the above example, must contain the data ‘PW’,
along with the FIELD.DISPLAY being set to ‘PWACTIVITY’.
And an ENQUIRY.NAME field on the ENQUIRY must contain the launch functions as in the above
example.
If the ENQUIRY is not set up correctly intermittent problems will occur, with activity status’s and
PW.ACTIVITY.TXN records not being updated, and mapping not working.
Now that the process has been created, running the ENQUIRY, PROCESS.STATUS displays all
activities and their statuses that can be or have been executed. Drilldown on the enquiry will allow the
chosen activity to be executed automatically.
The standard ENQUIRY record TO.DO allows activities to be listed per user, which allows a specific
user to concentrate on their allocated tasks.
With two stage applications LD and LD.SCHEDULES it is advisable to complete the activity before
launching applications via the explorer menu or command line.
Deal/Transaction processing
PW.ACTIVITY.TXN
PW.ACTIVITY.TXN Id’s are automatically generated by the system (as long as the
AUTO.ID.START record has been set up, see ‘Setting Up of the System’ document for PW), these
records cannot be created manually, the copy function is also not allowed.
PW.ACTIVITY.TXN.
This file contains the records of all activities that can be or have been executed. Once an activity has
been executed the TRANSACTION.REF field contains the ID of the record of the T24 or
EB.DYN.ACTIVITY application that was executed.
Upon completion of an activity, the system scans through the PW.PROCESS.DEFINTION record
and creates PW.ACTIVITY.TXN records for all activities that could be started if their
PRE.REQ.STAT has been met.
The field START.DATE contains the date on which the activity was created through PW.PROCESS.
The field DUE.DATE is calculated as the START.DATE + the number of working days, where the
number of working days is specified in the DEF.DURATION field of the respective PW.ACTIVITY
record.
For audit purpose the fields PARENT.PROCESS and ORIGINATE.PROCESS record information of the
originating process ID and parent processing ID.
MAPPING
A Working Example
Taking into account that the PW.VERB, PW.OBJECT, PW.PARTICIPANT, PW.STATUS and
PW.TRANSITION records have been created.
Two PW.ACTIVITY records are created; one to launch an Account application; the other to launch a
Funds Transfer application.
PW.ACTIVITY Record.
PW.ACTIVITY Record.
A PW.MAPPING record is created; this will detail where the data is to be extracted from and where it
is going to.
TABLE.TO details what type of T24 application this record is going to be attached to, in this case it is
an FT application.
DATA.NAME any description can be chosen so long as it matches it’s corresponding field
TARGET.VALUE.
DATA.SOURCE : This field dictates what data is being mapped and where it is coming from. In this
case the field CURRENCY in the PW.ACTIVTY record CREATE.ACCOUNT.
TARGET.FIELD is the data is being mapped to, this field must exist in the application detailed in the
TABLE.TO field, in this case FUNDS.TRANSFER.
PW.MAPPING Record.
The PW.MAPPING record is attached to the appropriate PW.ACTIVITY record in the MAPPING.ID
field.
MAPPING.ID field.
PW.PROCESS Definition.
PW.PROCESS Definition.
We can see that the Account Activity is first in the launch list.
The CREATE.ACCOUNT launches an ACCOUNT record that is populated and committed, note the
currency is CHF.
Account Record.
Once the Account record is committed and the Enquiry refreshed, the CREATE.ACCOUNT activity has
the committed record’s ID displayed.
CREATE.ACCOUNT activity.
@ID Mapping
Process Workflow can also map record ID’s to other application’s fields, in the example below the @ID
from the account activity is mapped to the DEBIT.ACCT.NO field in the application
FUNDS.TRANSFER
PW.MAPPING.
An OFS.SOURCE record needs to be created, the field SOURCE.TYPE should be GLOBUS and the
field SYNTAX.TYPE should be OFS. In the record below a Log has been created to track the OFS
scripts that TSA uses for mapping, see the OFS USER GUIDE for more details on OFS.SOURCE.
OFS.SOURCE record.
Two PW.ACTIVITIES are going to be used for the first test both are based on the ACCOUNT
application, the first is set up as usual with field ACTIVITY.TYPE set at MANUAL, a STATUS.CODE
set, the TARGET is a zero authoriser version.
PW.ACTIVITY.
The second PW.ACTIVITY record is where we will be mapping the data from the first activity too.
To signal this record to use TSA for the mapping function the ACTIVITY.TYPE is set to AUTO and
the OFS.SOURCE.ID is populated with the OFS.SOURCE record created earlier.
A PW.MAPPING record is also attached this will determined what is data is to be mapped, otherwise
the record is identical to that of the first activity.
PW.ACTIVITY.
The PW.MAPPING record is designed to for the second activity has used the PW.ACTIVITY record
ACCT.ACCOUNT1 as the source to map over the fields CUSTOMER, CATEGORY, ACCOUNT.TITLE.1,
CURRENCY, ACCOUNT.OFFICER.
PW.MAPPING.
PW.PROCESS.DEFINITION.
Now the TSA functionality will be activated, more on the TSA functions can be found in the COB
USER GUIDE.
Firstly an existing TSM.SERVICE record has the SERVICE.CONTROL field set to START the record
is committed.
TSA.SERVICE agent.
TSA.WORKLOAD.PROFILE record.
The record BNK/PW.MAPPING has the SERVICE.CONTROL field set to AUTO and committed.
TSA.SERVICE record.
PW.PROCESS.
The ENQUIRY TO.DO is launched and again displayed the first activity, this is executed manually.
Enquiry.
The ENQUIRY PROCESS.STATUS is launched to track the progress of the PW workflow, this shows
that the first activity has reached the status of complete and that a transaction reference has been
assigned to it, in this case it is an ACCOUNT ID
Note we have not activated the TSA functionality yet so the record will not be created yet)
Next two CLASSIC sessions are opened, drop down to jshell and initiate the Service Manager by
typing
In the other CLASSIC session type tSA 2 this will launch the TSA agent
When the first activity reached completed status an OFS SCRIPT was created, the TSA functionality
finds this script, and maps the relevant fields detailed in the PW.MAPPING record over in an
OFS.SCRIPT creating and committing a new record.
The Script produced when launching the tSA 2 agents shows that this has occurred.
Viewing the OFS.LOG record detailed in the OFS.SOURCE that is attached to the PW.ACTIVITY
record shows in the first line the OFS script created when the first activity was completed, then the PW
mapping by the TSA functionality that creates the full OFS script at the bottom of the LOG.
Once that has been run, the ENQUIRY PROCESS.STATUS is launched again we can see the
difference the TSA service has made, the second activity (which is the automatic creation of the
record) has been completed and been assigned a transaction reference. Because the second activity
has reached a status of complete the third activity can be displayed.
On viewing the ACCOUNT record created by the automatic activity we can see that the fields
CUSTOMER, CATEGORY, SHORT.TITLE.1, CURRENCY, and ACCOUNT.OFFICER HAVE been
successfully mapped over.
Enquiry.
The USER or ACCOUNT.OFFICER detailed in the PW.PARTICIPANT record must be the same as
the USER profile executing the workflow, so in the below example in order to use the new
functionality the USER profile of RICHARD01 will need to be used.
PW.PARTICIPANT.
The PW.PARTICIPANT record must be included in the Owner field in the PW.ACTIVITY record
being used.
Below the PW.ACTIVITY record has the PW.PARTICIPANT record of FT.GROUP to allow the
Auto Screen Presentation functionality to operate. All other PW.ACTIVITY records that are to be
subject to the auto launch functionality are similarly edited.
PW.ACTIVITY.
The PW.PROCESS.DEFINITION record contains all the PW.ACTIVITY records that are to be
included in the workflow, to allow the new auto launch functionality the new field FOLLOW.ON.ACT is
flagged to YES.
Note: In order to control the order in which the flagged PW.ACTIVITY records are launched the
PRE.REQ.ACT fields need to be used in order to allow this functionality to operate.
PW.PROCESS.DEFINITION.
A PW.PROCESS record is then created, note the same PW.PARTICIPANT record is used to
populate the OWNER field
PW.PROCESS.
As soon as the PW.PROCESS record is committed and authorised the new functionality
automatically launches the first Activity flagged for auto launch in the PW.PROCESS.DEFINITION
record with out having to launch a PW ENQUIRY e.g. TO.DO.
Customer.
Once the first activity has been committed and meets the required status to allow the second activity
to launch automatically
Note: that the ACCOUNT.OFFICER field has been populated showing that data mapping is operating
with in the new functionality.
Account.
Allows a PW.PROCESS to be automatically created in the background with no interaction from the
User except for a command line entry.
To do this, the following format will be input into the command line of T24 Browser.
Automatic screen presentation can be used in conjunction with Auto Process Creation to create and
display activities with out interacting with the PW ENQUIRY.
Using an auto presentation set up the command line is populated with the PW pre fix, the ID of the
PW.PROCESS.DEFINITION follows and then the PW.PARTICIPANT ID is populated.
Process Creation.
As soon as the command line is committed the PW.PROCESS is created and following the
PW.PROCESS.DEFINITION workflow the first activity is automatically presented to the user.
Customer creation.
In an example when auto presentation is disabled, the PW pre fix is entered the ID of the
PW.PROCESS.DEFINITION follows and then the PW.PARTICIPANT ID is populated in the
command line and committed.
Process Creation.
PW.PROCESS.
On launching the ENQUIRY TO.DO we can resume a normally manual launch of the workflow.
Data Mapping
To allow greater flexibility and to provide more options in Process Workflow mapping the application
EB.FORMAT.ENTRY has been linked to the PW module via EB.MAPPING.SOURCE.
Data Mapping will be replacing PW.MAPPING and no new PW.MAPPING records will be allowed.
This will allow mapping options such as universal ID mapping, the ability to manipulate data through
concatenation of fields, using routines, universal local reference mapping and the mathematical
operator’s addition, subtraction, multiplication, division.
The new Data mapping options can work side by side with the current mapping functionality provide
for in PW.MAPPING. In the event that the Data mapping and PW mapping methods should clash
preference will be given to the current PW mapping method.
To use Data Mapping the following will need to be set-up, the PW.ACTIVITY record will need to
reference to a EB.MAPPING.SOURCE record which will communicate between the current Process
Workflow functionality and the mapping options available in EB.FORMAT.ENTRY.
Like using PW.MAPPING the mapping instructions are attached to the target PW.ACTIVTY.
The field EB.MAPPING in the application PW.ACTIVTY record will direct the workflow to use the
mapping instructions and options available in EB.MAPPING.SOURCE.
PW.ACTIVITY.
The EB.MAPPING.SOURCE record provides a description field for the record and also details the
target application in the field TABLE.TO.
There are two sets of multi values, the first set is used when mapping record ID’s the second when
mapping field data.
FLD.SRC.FLD/ID.SCR.TYPE is used to identify what type of source the data is coming from, a
Routine another PW activity or other source. ID Mapping into the first activity record in a workflow can
not be done but you can carry out mapping into fields of the first activity.
FLD.DATA.SRC/ID.DATA.SRC further defines the details of the data source, usually the name of the
routine or the PW activity.
FLD.EB.FMT.ENT is name of the EB.FORMAT.SOURCE record and will give instructions of the type
of mapping that is to take place.
LOG.LEVEL This defines logging options on the event of an error in the mapping workflow, the LOG
option will allow the workflow to continue but raise an entry in EXCEPTION.LOG.FILE, the BLOCK
option will raise the same entry and halt the workflow with an error message. The NULL option will do
none of the above.
EB.MAPPING.SOURCE.
The EB.FORMAT.ENTRY record provides details of what the mapping is to, do the fields
SHORT.DESC, FMT.DESCRIPTION and DESCRIPTION are all reporting fields and can contain any
information
The EXTRACTION field defines what information is mapped, the first command is what is done to the
information, the second part is which application it is coming from and the third is the field.
The PLACEMENT field defines where the information is going to, the first command is what is done to
the information, the second part is which application it is going to and the third is the field.
For further information on the field option in EB.FORMAT.ENTRY please see the applications help
text.
The below example shows a field to field mapping instruction, the EXTRACTION field extracts the data
from the application CUSTOMER field OTHER.OFFICER. The PLACEMENT field replaces any data
in the application ACCOUNT field OTHER.OFFICER with the data from the PLACEMENT field.
EB.FORMAT.ENTRY.
In addition to the EB.FORMAT.ENTRY commands new ones have been added for Data Mapping
For example.
This EB.FORMAT.ENTRY record will take the application nominated by EB.MAPPING.SOURCE
and map its Company ID to the field nominated in the PLACEMENT.
EB.FORMAT.ENTRY.
ID mapping,
With Data Mapping PW can map from record ID’s and into Record Id’s
The following example will map the data from the CUSTOMER field in ACCOUNT application and
populate the @ID in the second activity which is a CUSTOMER application.
Firstly note that the ID multi value set is being used not the Field multi value set.
The EB.MAPPING.SOURCE record identifies the application it is mapping to in FIELD.TO, the
ID.SRC.TYPE is a PW.ACTIVITY, the source of the data is detailed in ID.DATA.SOURCE and the
mapping rules as laid down in the EB.FORMAT.ENTRY record FIELD.TO.ID as per the
ID.EB.FMT.ENT field.
EB.MAPPING.SOURCE.
The mapping instructions in EB.FORMAT.ENTRY has the EXTRACTION field copy the data in the
field CUSTOMER from the ACCOUNT application.
The PLACEMENT field uses the A command to append data to the first field in the target application
which will be the record ID.
EB.FORMAT.ENTRY.
The EB.MAPPING.SOURCE shows that the target application is ACCOUNT, and the data source
is a PW.ACTIVITY called CREATE.CUST and the EB.FORMAT.ENTRY record used for mapping
is ID.TO.FIELD.
EB.MAPPING.SOURCE.
The mapping instructions in EB.FORMAT.ENTRY has the EXTRACTION field pick up and store the
&&SOURCE.KEY&& which is the command for the target application’s ID field.
The PLACEMENT field copies the mapping data in to the target field CUSTOMER in the ACCOUNT
application.
EB.FORMAT.ENTRY.
ID to ID mapping
Below is a EB.FORMAT.ENTRY that will copy a @ID to another @ID field.
Both EXTRACTION and PLACEMENT field commands have been used in the past two examples.
EB.FORMAT.ENTRY.
To map local references just use their field name in place of the normal field name, below the local
reference field TEST in the application ACCOUNT is being mapped to the local reference field
SYMBOL in CUSTOMER application.
EB.FORMAT.ENTRY.
Concatenation of fields
The next example will show how to select two source fields to map and concatenate the selected data
in to one target field.
An EB.MAPPING.SOURCE record is created as normal, note that the Field multi-value set is being
used.
EB.MAPPING.SOURCE.
The multi-value set in EB.FORMAT.ENTRY is expanded and the first EXTRACTION and PLACEMENT
fields are populated as if carrying out a normal field to field mapping instruction.
In the second multi-value set the second field is selected in the EXTRACTION field and the placement
field uses the NA command when appending the second value to the first value.
EB.FORMAT.ENTRY.
Mathematical operators
(Addition, subtraction, multiplication, division)
Data mapping can carry out basic mathematical calculation in its mapping functions by a simple
command in the PLACEMENT field in the EB.FORMAT.ENTRY application.
Below the example record shows that the multi-value set has been expanded and the first value is
mapped from the FRISTVALUE field in the CUSTOMER application and the placed in the local
reference field ADDITIONRESULT in the ACCOUNT application.
Then a second value is mapped from the local reference field SECOND.VALUE in the ACCOUNT
application and placed in the local reference field ADDITIONRESULT in the ACCOUNT application.
Note the placement field in the second multi-value has the command NP this will instruct Data
mapping to add the two values together.
EB.FORMAT.ETNRY.
The EB.MAPPING.SOURCE record setup differs from other napping operations, here we have
nominated ROUTINE as FLD.SRC.TYPE and the FLD.DATA.SRC is populated with the name of the
routine prefixed by the @ symbol.
EB.MAPPING.SOURCE.
EB.FORMAT.ENTRY.
Literals
Data that is to be mapped can also be defined in the EB.FORMAT.ENTRY application; it can also be
mapped to the first PW.ACTIVITY record in the PW.PROCESS.DEFINITION.
In the below example the EB.FORMAT.ENTRY record has a literal defined in the EXTRACTION field,
it will copy the data after the comma i.e. 1000.
The PLACEMENT field will place this literal data in to the SECTOR field in CUSTOMER.
EB.FORMAT.ENTRY.
To use this mapping in the first PW.ACTIVITY the associated PW.MAPPING.SOURCE will need
to be attached to the first PW.ACTIVITY record in the PW.PROCESS.DEFINITION.
Reports
Duration Analytics
To enhance reporting, additional duration data has been added to the PW.ACTIVITY.TXN table.
The time the PW.PROCESS was created, each time the PW.ACTIVITY.TXN under goes a status
change and finally completes will be recorded so that the time each activity took, how long it spent in
different statuses can easily be calculate.
The below record displays a START.DATE and DUE.DATE for the PW.ACTIVITY.TXN, these are set
in PW.PROCESS.
The three sets of Times and Dates are displayed:
The first set gives the start time it of the PW.PROCESS record.
The second set gives the time and date the PW.ACTIVITY.TXN record was created.
The Third and final set gives the time and date the PW.ACTIVITY.TXN goes to a completed status.
PW.ACTIVITY.TXN.