Ilide Info pw1 Setting Up A Workflow r17 PDF PR F58e679e4485b7f

Welcome to ‘Setting up a Workflow in T24’ learning unit of the Process
Workflow Course. In this learning unit, you will learn about creating workflows in
T24.
PW1.ProcessWorkflow-R17 1
After completing this learning unit, you will be able to:
Identify the applications involved in creating a workflow

Create a sample Workflow in T24
Launch the Workflow
What do you understand by the words process and workflow in general?
Process is a series of actions or steps taken in order to achieve a particular end.

Workflow is the sequence of industrial, administrative, or other processes through
which a piece of work passes. Therefore, Process Workflow is a series of steps through
which work is routed to achieve a result. Examples of real-time workflows are Customer
Feedback processes, Employee appraisal workflows etc.
Now that you know the meaning of Process Workflow, what do you think could be the
need for Process Workflow in T24?
All banks have processes defined even for the simplest of activities. The Process
Workflow product allows you to build these processes into T24. In short, the PW module
is aimed at grouping various business and banking activities into logical processes. The
advantage of this module is that, a process can be handled with the least amount of
business expertise.
For example, Mr. Brown who is currently not a customer of your bank, walks in and
wants to open an account. Does he go straight to the account opening desk? The bank
will have a process defined for circumstances like this. Firstly, the bank needs to know
whether Mr. Brown is an existing or a new customer. Based on the information provided,
you might have to either open a current account or savings account.
Let us consider the example of an account opening process.
When Mr. Brown walks into the bank to open an account, the bank will first gather his
basic details. This can be achieved by issuing a form which can be filled in by the
customer or a bank representative.
One thing that we must remember here is that when a bank creates a process, it must
cater to all possible options. In the account opening process we must also cater to a
situation where an existing customer who already has an account, wants to open
another one.
Once basic details are collected, the bank must decide whether the person is eligible to
open a Savings account or a Current Account. The bank might also want to record
customer signature for future reference.
In the previous slide you have seen an example where you can set up a process
workflow to open an account. There are various applications involved in this process.
Each such application screen is called an ‘ACTIVITY’ in PW. The activity essentially forms
a part in the chain of activities that are together known as process. An instance of an
activity attains a particular status. Further activities could be dependent on the previous
activity and/or its status.
With reference to the same example, there should be a particular order to input records
in various applications to open an account. Activities proceed or transit from one to
another. For PW to decide what activity is to come next, you must set up a condition
which is called the ‘TRANSITION’. This transition rules determine the end output of a
particular activity which is further used to determine the method and route of further
activities.
Only if the transition or condition returns a particular favorable value, you will be moved
on to the next activity. Any possible outcome of an activity is referred to as ‘STATUS’ in
PW. Based on the values input in an activity, a status is assigned to it.
A process or activity is performed by multiple users in the bank. A user could belong to
different groups that have different privileges to work upon certain activities. Also
certain activities are allotted to certain groups by default. ‘PARTICIPANTS’ refer to set of
users who are grouped together in an effort to work upon certain activities.
Activities are grouped together to define a process. Certain activities in a particular
process are conditional. All activities within a process could be sequential or could be a
combination of sequential or parallel. Every process has got a logical conclusion and/or
different exit routes. Putting all the above mentioned components together and defining
the process workflow is referred to as ‘PROCESS DEFINITION’.
Now try relating the account opening process to the PW terms. When a
customer walks in to the Bank, you have to decide whether or not he is a
corporate or individual customer and whether he is new or an existing customer.
Therefore you have to decide on the status of the customer. Transitions are
defined in PW.TRANSITION
The bank must set some conditions or transitions to check if the customer is new
or existing or corporate or individual.
Based on transitions, bank decides on the status. Some examples of STATUS –
NEW, EXISTING. Status of activities is defined in PW.STATUS
Then the actual task is done by performing a particular activity. E.g. Create
customer record, Create An Account, Capture Signature. Activities are defined in
PW.ACTIVITY
Once you have created the TRANSITION, STATUS, ACTIVITY , you should put them
all together to make it a PROCESS. Processes are defined using
PW.PROCESS.DEFINITION
Applications Required to create a PW.ACTIVITY are
PW.VERB
PW.ACTIVITY.OBJECT
PW.STATUS
PW.TRANSTION
PW.ACTIVITY
Lets discuss each of the applications
PW.VERB
ID: The ID of a record in PW.VERB can be any meaningful text.
GB DESCRIPTION: The field DESCRIPTION holds the brief description of the
record.
PARENT: The PARENT field can hold the ID of the record from the same
application which can be used at a later stage for nesting processes and this field
will indicate a parent/child association.
PW.ACTIVITY.OBJECT
ID: The ID of a record in PW.ACTIVITY.OBJECT can be any text which describes
the object of the activity.
DESCRIPTION: Holds the brief description of the record.
DEFAULT.TARGET: If a value is input in the field DEFAULT.TARGET, it will be
defaulted in the field TARGET in PW.ACTIVITY while creating an activity, which is
used to execute the activity. The default is not mandatory and can be
overwritten in any activity.
Any activity can be considered as a verb and object: Create Customer, Create
Account, Create Contract, Amend Account
The id of PW.VERB and PW.ACTIVITY.OBJECT together form the id of
PW.ACTIVITY. For example, if the ID of an PW.ACTIVTY is CREATE.LOAN, then the
first part CREATE should be a record in PW.VERB and the second part LOAN should be a
record in PW.ACTIVITY.OBJECT.
If you consider the flowchart, the bank must decide on the status of the customer
whether new or existing to resolve on the workflow. PW.STATUS application
contains the various status codes that could be used to attach to different
activities. The status are defined separately so as to allow reusability. Status codes
represents the values returned by activities based on conditions that are satisfied.
ID: The ID of a record in this application is a user defined descriptive key which is
used to define the status of an activity in PW.
DESCRIPTION: This field holds the description which will be used for enrichment
purpose.
SHORT.DESC: This field holds the ID in the abbreviated form which will be used
while generating reports.
There is no business logic built into this application.
PW1.ProcessWorkflow-R17 12 12
Based on the conditions whether the customer is new or existing, the appropriate activities
should be triggered. The conditions are specified in the application PW.TRANSITION.
For example, We could have a transition to check if ACCOUNT record (in the current activity) is a
NOSTRO account. Then the activity could chain to a different activity that collects specific
details for nostro accounts. Therefore, transition helps in streamlining the workflow defined for
a particular process based on the dynamic nature of the data being input. Transitions can be
simple like checking of a value of a field in the record or a routine to be executed or could be
combination of both.
ID: The ID can be any meaningful text to identify the record of the application.
GB.DESCRIPTION: This field holds the brief description of the ID.
SELECTION.FIELD: This holds valid field number or field name of the application associated with
the PW.ACTIVITY record. It can also hold a local reference field. If Selection field is multivalued,
AND condition will be applied between the fields. i.e. – all conditions have to be met.
OPERAND: This field specifies the type of comparison to be made between the contents of the
field indicated in SELECTION.FIELD and the value specified in the CRITERIA field of
PW.TRANSITION application.
CRITERIA: This field specifies the value with which the contents of the field indicated in
SELECTION.FIELD are to be compared.
SELECTION.OPERAND: Possible values in this field are ‘AND’ and ‘OR’ to combine multiple
conditions. When selection field and a routine are combined, the operator can be AND/OR.
ROUTINE: The field ROUTINE holds the local routine name which needs to be executed to
continue with the process. The routine must return one argument containing an error if
conditions or rules within the local routine are not met.
PW.PARTICIPANT is the application where the end users for each workflow are defined. The grouped
users can be made as default owners of activities and processes. Hard coding of one user to one
activity is possible or you can also allot one group of users per activity. Participants should be valid
T24 users or department account officers.
ID: The ID of a record in this application can be any meaningful text.
GB DESCRIPTION: This field holds the description of the record and is used as enrichment for the ID.
GB SHORT.DESC: holds the description in abbreviated form, which can be used for reporting
purposes where space is limited.
ACCT.OFFICER: This field allows to enter a valid DEPT.ACCT.OFFICER key .
USER: The field USER is Multi-value field and is used to define list of T24 users who can execute the
activities defined in the process. A PW.PARTICIPANT record can contain either USERS or
ACCT.OFFICERS
LAST.USER : The value in the field LAST.USER indicates the USER from the multi-value list of USERs
who was assigned to a PW.ACTIVITY.TXN. This is automatically populated with each new
PW.ACTIVITY.TXN record that has been created.
LAST.DAO: The value in the field LAST.DAO indicates the DEPT.ACCT.OFFICER from the multi-value list
of ACCT.OFFICER who was assigned to a PW.ACTIVITY.TXN. This is automatically populated with each
new PW.ACTIVITY.TXN record that has been created.
ALLOW.EXT.USR : The field ALLOW.EXT.USR is used to define whether the users other than the ones
mentioned in the USER field or ACCT.OFFICER can execute the activity or not. External user can
execute the activity only if this field is set to ‘y’. Only internet banking users defined in
EB.EXTERNAL.USER can execute the activity .
Other T24 users, not defined as part of the PW.PARTICIPANT record will not be able to execute the
activity/process and the error This task has been assigned to a different user will be raised
All the activities are defined in PW.ACTIVITY. Information entered in this application includes
the screen that must be displayed to the user which represents a T24 application or version, the
Conditions that must be checked before deciding on what status code must be returned by the
activity, USER who has the privileges to execute the activity and whether the fields of this
activity are populated with data from other activities.
ID: The ID of PW.ACTIVITY should be combination of IDs in the application PW.VERB and
PW.ACTIVITY.OBJECT .
GB DESCRIPTION: Holds the meaningful description of the activity.
GB SHORT.DESC: Describes the PW.ACTIVITY record in an abbreviated format, which can be
used for reporting.
DEF.DURATION: Holds the maximum number of days that can be used to complete the activity.
Note: Even if the activity is executed after the number of days specified in this field, there is no
error/override message. This is just an informative field. Can be used for reporting purposes.
For example, to query the activities that are still pending, even beyond the DEF.DURATION.
ACTIVITY.TYPE: Holds a value MANUAL or AUTO where MANUAL denotes that the activity
should be manually executed from the enquiry and AUTO denotes that the activity should be
executed automatically via OFS. If this field is set to AUTO, an OFS string is used to input values
into the fields and is automatically executed. T24 will complete the activity automatically and
pass on to another activity based on the resulted status.
STATUS.CODES: Holds the status code that will be set if the conditions defined in
PW.TRANSITION is satisfied. The entry in this field should be a valid ID of a record in PW.STATUS
application.
STATUS.RULES: STATUS.RULES holds the ID of the record in PW.TRANSITION where the rules are
specified. Both these fields form an associated multi value set.
EVAL.RULE: This field can accept any valid keys of EB.RULE.GATEWAY application. This is
mutually exclusive with the STATUS.CODES and STATUS.RULES multi-value set
COMPLETE.STATUS: Can accept any valid ID of the application PW.STATUS. The value in this field
determines the completion status of the respective activity
Therefore even before you create an activity record, you must remember to create records in
PW.VERB, PW.ACTIVITY.OBJECT, PW.TRANSITION and PW.STATUS.
OWNER: The field OWNER holds the ID of the PW.PARTICIPANT record which lists the USERs or
ACCT.OFFICERs that will be allocated to the activities in the process. If this OWNER field is not set
then the OWNER field on the PW.PROCESS record will be used to determine ownership of an
activity.
TARGET: this field holds the T24 Application/Version/Enquiry and Function which should be
presented to the USER upon the execution of the Activity i.e. the Application/version/Enquiry
associated with the Activity. For example, if a new Id is to be generated upon the execution of an
activity then the entry in this field would be like ACCOUNT, I F3. If any application or version name
is mentioned in the field DEFAULT.TARGET of associated PW.ACTIVITY.OBJECT then it will get
defaulted when trying to create a new PW.ACTIVITY.
DEF.STATUS.CODE: The field DEF.STATUS.CODE holds the ID of PW.STATUS which will be assigned
to the activity when it is being executed. On completion of the activity, based on the rules
specified, it will return another status code.
Imagine there is an activity within a given workflow, that gets all its data from past activities. In
order to eliminate redundant data input, mapping can be set up. In this case, the activity type
can be set to AUTO. What actually happens is, a service, namely BNK/PW.MAPPING will pick up
all PW.ACTIVITY where the ACTIVITY.TYPE is AUTO. Using OFS (simulates user input), these
activities are then executed.
MAPPING.ID: The value in the field MAPPING.ID is a PW.MAPPING key which contains all the
data mapping rules for the APPLICATION that is launched via this PW.ACTIVITY record.
OFS.SOURCE.ID: The field OFS.SOURCE.ID holds the name of the OFS.SOURCE record ID which is
used by the service PW.MAPPING to execute the activity via OFS. This field is mandatory
ACTIVITY.TYPE is AUTO
EB.MAPPING : The mapping functionality uses EB.FORMAT.ENTRY module and is attached to
the current PW module through EB.MAPPING.SOURCE. You will learn more about mapping in
the next learning unit.
ALT.OWNER : This field holds the id of an API hook routine which returns participant or user to
be allocated for the PW.ACTIVITY.TXN for this activity.
EXPIRATION.HOURS : Specifies the duration in hours before the activity expires. It is used with
reference to the DEF.DURATION and EXPIRATION.MINS field.
EXPIRATION.MINS : Specifies the duration in minutes before the activity expires. It is used with
reference to the DEF.DURATION and EXPIRATION.HOURS field.
MONITOR.STAGE : Can take the values START,COMPENSATE,FAULT. This field should be set to
START to record the duration metrics of the Activity. The fields MONITOR.INIT.DATE,
MONITOR.INIT.TIME, DUE.DATE and DUE.TIME of the corresponding PW.ACTIVITY.TXN record
get updated only if the value set to START.
Now that you have defined the activity, conditions, status codes and the users,
the next step would be to put them all together to form a template for a
particular process. The whole process of creating an account for a customer is
defined as a process workflow. This can be done using PW.PROCESS.DEFINITION
application. This application enables you to link different activities to make up a
logical process. This table defines the sequence of various activities and their
dependencies. An activity could be attached to a process as independent activity
or dependent on the completion of a previous activity. Further, the activity can
also be triggered only on appropriate status of the previous activity.
ID: The ID of the record can be any text which describes the process.
GB DESCRIPTION: Holds the description of the ID which is used for enrichment
purpose.
GB SHORT.DESC: Holds the abbreviated form of the record ID which is used for
reporting purposes.
DEF.DURATION: Holds the maximum number of days with in which the process
must be complete. Its only for an information
ACTIVITY: Holds the name of the activity that has to be executed. Should be a
valid PW.ACTIVITY ID.
PRE.REQ.ACT: Holds the ID of the pre-requisite activity that needs to be
completed before you move on to the activity mentioned in ACTIVITY field.
PRE.REQ.STAT: Holds the status code that must be returned by the activity
defined in the field PRE.REQ.ACT. If the status that is returned by the activity
mentioned in the field PRE.RE.ACT does not match to what is defined in this
field then the corresponding ACTIVITY defined cannot be executed.
PRE.REQ.RULE: Holds a valid PW.TRANSITION ID where the conditions pertaining
to the activity are defined. Only if the rules mentioned in this table are met the
activity can be executed. The activity mentioned in the field PRE.REQ.ACT can
either be dependent on itself, or on PRE.REQ.STAT or on PRE.REQ.RULE. The
fields PRE.REQ.STAT and PRE.REQ.RULE are mutually exclusive.
OPERATION: Can hold a value of ‘AND’ or ‘OR’ or left blank. This field can be
used if more than one condition must be satisfied for the activity.
UNIQUE.NAME: Can be used when the same activity is used multiple times
in a single process definition to differentiate its several occurrences.
TIME.TRIGGER: A facility whereby the status of an activity is evaluated by a
tSA service as opposed to a user interaction on the process.
FOLLOW.ON.ACT : Can hold a value of ‘YES’ or ‘NO’ or left blank. This is a
facility where T24 automatically presents an input screen to a user without
them directly requesting it based on the definition of the activity within the
workflow. If the field ACTIVITY.TYPE is set to ‘AUTO’ in PW.ACTIVITY then the
current field cannot be set to ‘YES’, because if AUTO activity is set then T24
will automatically complete the activity whereas setting current field to YES
will open up the next activity for input by the user. The underlying routine
that automatically brings up the next activity is EB.SET.NEW.TASK
EB.MAPPING: Specifies the mapping to perform on the current activity of the
process.
PATTERN.CONSTRUCT: This field is used to define a specific workflow pattern
construct. There are three pattern construct options like ROUTE.TO,
PARALLEL.FLOW and SWITCH.
EVAL.CONDITION: This field is used in conjunction with the Loop (ROUTE.TO)

and Switch(SWITCH) pattern constructs in the process definition. It can hold
values from the EB.API application. The”@“ symbol should be added with
the EB.API id for ex. @Route condition.
ACTIVITY.OWNER: Specifies the user(s) who is/are privileged to execute this

activity. Having precedence over the owner field of PW.ACTIVITY. Used to
override the default owner assigned at activity level in
PW.PROCESS.DEFINITION.
PROCESS.COMPLETION.STATUS: Defines the status which when reached means
the process is complete. Value in this field must have an existing code on
PW.STATUS.
ALLOWED.STATUS: Can hold any valid status which can be assigned to the
process.
PROCESS.ACTIVITY: Must hold the last activity name in the process that needs to
be completed for the process to be completed.
ACTIVITY.STATUS: Holds a defined status where when the activity mentioned in
PROCESS.ACTIVITY reaches this status then the process will be assigned the
status of the associated ALLOWED.STATUS field. The status mentioned here must
be an allowed status for the activity as defined on the PW.ACTIVITY record.
OWNER: Holds a valid ID from PW.PARTICIPANT where these users can execute
the activities defined in the process.
You have already created activities. In this workshop, you have to create a
process with the activities done in the earlier workshop.
You are now familiar with all the applications involved in creating a process workflow.
You have been accessing the applications by keying in the application name in the
command line. You can also use the ‘Business Tools’ option under ‘Admin Menu’ to
create or amend all the PW related records. On clicking on the ‘PW Builder’ tab, you can
see tabs to setup various applications. Under the ‘Rule’ tab, click on ‘Define Status’ link
to launch PW.STATUS application and ‘Define Transition’ to launch PW.TRANSITION
application.
In the ‘Activity’ tab, use the ‘Define Participant’ link to launch PW.PARTICIPANT
application, ‘Screen Definition’ to create a version, ‘Define Verb’ to launch PW.VERB,
‘Define Activity Object’ to create PW.ACTIVITY.OBJECT record and ‘Define Activity’ link to
create PW.ACTIVITY records.
Use the ‘Process’ tab to create a PW.PROCESS.DEFINITION record in T24.
You have so far created a template which can be re-used. The next step after you set up
the process is to execute it. How do you execute the process? You have to run an
instance of the template. Each time a workflow has to be executed, a unique instance of
a particular process is created.
A process can be executed using from the User Menu  Business Tools  Process
Workflow Operations Start a Process. When you click on this link, an instance of the
template created for a particular process is run and opens a new record in the
application PW.PROCESS for execution. Information related to all instances of various
processes are stored in this application. A new record is created for every instance of the
process. This application marks the beginning of a process. Once the record in the
application PW.PROCESS is authorized, a record in another application PW.ACTIVITY.TXN
is created automatically by T24.
PW.ACTIVITY.TXN contains all the activities have been executed. These are the two
applications that are involved in execution of a process. In other words, upon the
completion of an activity, system scans through the PW.PROCESS.DEFINTION record and
creates PW.ACTIVITY.TXN records for all activities that could be started now. For each
and every activity in a process, a record is created in PW.ACTIVITY.TXN only when a
particular activity is available for execution.
For example, if in a process, there are four activities that are dependent on their
previous activity, then on authorization of the respective PW.PROCESS record, the
system creates the PW.ACTIVITY.TXN record only for the first activity. The system will
not create for the second activity as it is not yet available. When the first activity is
invoked by the user and the activity is completed, the system will then create the
PW.ACTIVITY.TXN record for the second activity.
When CUSTOMER record is committed, the ACCOUNT creation screen is
presented. When the ACCOUNT is committed, the FT screen is displayed.
PW.PROCESS application is used for executing the process. In the screen shot
given, a version of the PW.PROCESS application is used. On committing the record
in this application, activities gets triggered. The first activity defined for the
ACCOUNT.OPENING process is ‘Interview Info’, which gets triggered when you
commit the respective record in PW.PROCESS. On completion of this activity, the
next activity opens up for input and so on.
At any point of time during execution of a process, if you want to know the
status of activities, you can open the record in PW.PROCESS in ‘SEE’ mode which
is updated with the status of the activities.
You will now understand the fields of a record in PW.PROCESS application.
ID: The ID of the record is in the format PW<YYDDD><NNNNN> where PW
stands for the application, YY denotes the year, DDD denotes the Julian date and
NNNNN stands for a unique number from 00001 to 99999.
PROCESS DEFINITION : This field holds the ID of the record from
PW.PROCESS.DEFINITION for which you want to execute a workflow. The record
is read to find out the first activity to be executed.
CUSTOMER: Used for Data Mapping. If the customer for the process is known
the customer number can be input here which can then be used to default the
customer details in a PW activity record.
OWNER : The OWNER field holds a valid PW.PARTICIPANT record ID defining
which user group is responsible for this process. All the users belonging to one
group will be allocated to a PW.ACTIVITY.TXN record on a rotational basis.
START.DATE : Holds the date on which the record in PW.PROCESS is created.
DUE.DATE : This field is a no input field. The value in this field is calculated by
adding the value in the field DEF.DURATION from the PW.PROCESS.DEFINITION
application to the value in the field START.DATE.
COMPLETION.DATE: COMPLETION.DATE field is populated by T24 when the final
activity in the process is completed. The PROCESS.COMPLETE field in
PW.PROCESS.DEFINITION is used to populate the date in COMPLETION.DATE in
PW.PROCESS.
ACTIVITY.TXN : The field ACTIVITY.TXN holds the ID of the corresponding record
from PW.ACTIVITY.TXN application for the current activity.
COMPLETED: COMPLETED field holds the information on the completion of the
PW.ACTIVITY.TXN record.
ACTIVITY: The ACTIVITY field holds the ID of the record from PW.ACTIVITY
application that is being run for the particular PW.ACTIVITY.TXN record mentioned
in the field ACTIVITY.TXN.
UNIQUE.NAME : The UNIQUE.NAME holds the corresponding value defined in
the PW.PROCESS.DEFINITION record for the activity. All the fields from
ACTIVITY.TXN to UNIQUE.NAME form a multi value set and are updated by the
system.
PROCESS.STATUS : The field PROCESS.STATUS indicates the overall status of the
process. The value is populated depending upon the value mentioned in the field
ALLOWED.STATUS in PW.PROCESS.DEFINITION.
PARENT.PROCESS : The field PARENT.PROCESS holds the ID of the
PW.PROCESS.DEFINITION which acts as a parent process where the current
process is a subset of the parent process defined in this field.
Once the first activity to be executed is identified, a new record in PW.ACTIVITY.TXN
application is created automatically by T24. This record cannot be modified. Details of the
current activity are updated in this record. Each activity has a separate record in this
application. The records are created only when the particular activity is available for launching
and there are no pre requisite activities to be completed. The appropriate PW.PROCESS record
is updated with the details of the current activity being executed.
ID: The ID of the record is in the format PA<YYDDD><NNNNN> where PA stands for the
application, YY denotes the year, DDD denotes the Julian date and NNNNN stands for the
unique number which varies from 00001 to 99999.
PROCESS: The field PROCESS holds the PW.PROCESS ID to which this activity transaction
belong to.
ACTIVITY : The ACTIVITY field holds the ID of the PW.ACTIVITY record that is being executed.
OWNER : A valid PW.PARTICIPANT ID which is a valid group to execute this activity is defined in
the field OWNER.
USER: The field USER holds the user that is automatically allocated to the current activity
transaction.
START.DATE : The field START.DATE holds the date on which PW.PROCESS record is created.
DUE.DATE : The DUE.DATE field holds the date by which the whole process should be
complete.
COMPLETION.DATE : The field COMPLETION.DATE holds the date on which PW.ACTIVITY.TXN
record is complete and is updated automatically by T24. The activity transaction is said to be
complete when the STATUS.CODES and STATUS.RULES have been met and the complete flag
for these fields is ‘Y’.
TRANSACTION.REF : The field TRANSACTION.REFERENCE holds the key to the activity
that was just run. For example, if a new ACCOUNT record was created the new account
number would appear in this field as the transaction reference for the activity of
opening a new account. A concat file PW.TXN.REF is also updated with the transaction
reference for later reference and easy retrieval.
TARGET : The field TARGET holds the text that could be run from the command line.
PW.ACTIVITY.STATUS : The field PW.ACTIVITY.STATUS holds the last status of the activity
transaction that is to be returned after all the conditions set are met.
ACTIVITY.TYPE : The field ACTIVITY.TYPE is automatically defaulted form the field
ACTIVITY.TYPE form PW.ACTIVITY record. T24 uses OFS and a service PW.MAPPING to
enable you to define AUTO activities.
MAPPING.COMP : The field MAPPING.COMP is set to 'Y' when the activity gets executed
for the first time and mapping is done. This is to avoid doing the mapping again when
the activity is re-executed.
START.TIME : The START.TIME field holds the time when the activity could have been
started or when the pre requisite tasks have been completed.
STATUS, END.DATE and END.TIME : The fields STATUS, END.DATE, END.TIME form an
associated multi value set. Every time the status changes, the date and time are
recorded to determine how long the activity was in a specific state.
ORIGINATE.PROCESS : PW allows one process to be embedded into another. The field
ORIGINATE.PROCESS holds the PW.PROCESS ID which created the entire PW instance.
This field is used to fetch all the PW.ACTIVITY.TXN records of a particular PW instance.
After you have initialized the workflow, how do you actually execute the activity?
By running an ENQUIRY PROCESS.STATUS from the command line. A list of all activities
for all instances is displayed. The PROCESS.STATUS enquiry is based on the
PW.ACTIVITY.TXN application. Use the ‘Execute Activity’ link to launch the activity.
Activity can be reassigned by clicking on the reassign link.
The field TRANSACTION.REF in PW.ACTIVITY.TXN holds the key to the activity
that was just run. A concat file PW.TXN.REF is updated with the transaction
reference for later reference and easy retrieval. This reference can be used to
keep track of the activity even if it is not launched from the enquiry screen or
does not use the target version. Meaning, once you start the process, you can
execute the activity even via CUI and is still treated as completion of an activity
in the process. So irrespective of what version is used to perform an action on a
transaction that is part of a workflow, T24 updates its status since it knows which
instance it is part of.
The ID of the record in this file is <application name>*<transaction reference

number>. Example ACCOUNT*40673
This record has only one field that holds the value of the associated
PW.ACTIVITY.TXN ID.
Execute the process created in the earlier workshops and view the records in
PW.PROCESS, PW.ACTIVITY.TXN .
Note: SOURCE.TYPE will always be taken as GLOBUS. The SYNTAX.TYPE must be
OFS. The OFS messages can be seen in OFS.REQUEST.DETAIL application
SOURCE.TYPE for the PW.MODEL record is set as TELNET. But it is hard-coded as
GLOBUS in the routine. The above example uses two different PW.ACTIVITY
records to create ACCOUNT as for the FT, the account ID is mapped to
DEBIT.ACCT.NO in one case and CREDIT.ACCT.NO in the other.
In the screenshots above, you can see the process definition record and the
records used for mapping the ACCOUNT ID to the FT record.
The process is initiated and the version for the first activity is displayed. Once the
activity is completed, two activity txn for account creation is available.
The enquiry shows the ACCOUNT creation is in pending status and owner is OFS.
Set SERVICE.CONTROL to START and start the service.
After the service is started, required accounts are created using OFS messages.
The next activity is launched and the account numbers are mapped. The FT is
completed by providing other required values.
Using pattern based workflow, it is It is possible to
• Perform an activity many times if required
• revisit completed activities
• Execute activities in parallel
• Branch to a required activity
We will understand pattern based workflow in a later session
All PW related common variables are stored in the common file called
I_PW.COMMON
The PW.PARAMETER application is the parameter table for the PW product.
The application only has one record SYSTEM.
PW.PARAMETER specifies retention period for records of PW.PROCESS and
PW.ACTIVITY.TXN. Mov.hist.date and retention period are mutually exclusive and
records of PW.PROCESS and PW.ACTIVITY.TXN records are archived if the
COMPLETION.DATE of PW.PROCESS record is older than or equal to this date.
(Number of days the record is retained in live file after PW.PROCESS is
completed)
The online service PW.PROCESSING has a multi threaded job PW.MOV.TO.HIS,
which moves all the records whose completion date is less than the
MOV.HIS.DATE or older than the RETENTION PERIOD in PW.PARAMETER from the
live file into history file $HIS. It does it for both PW.ACTIVITY.TXN records as well
as PW.PROCESS records.
USE.WORKFLOW.PATTERNS allows to define pattern based workflow only if the
value is set to YES
The enquiry ACTIVITY.DEFN.LIST is based on the PW.ACTIVITY application and
lists all the defined activities.
ENQ PROCESS.DEFN.LIST
The enquiry PROCESS.DEFN.LIST is based on the PW.PROCESS.DEFINTION
application and lists all the existing process definition records.
The enquiry has options to drill down and edit process definition or activities or
the versions involved in PW.
ENQ PROCESS.STATUS.VIEW
The status of each activity in a process can be tracked using the enquiry
PROCESS.STATUS.VIEW.
The enquiry shows the current status of activity along with its activity name, and
if there is any construct defined in that activity.
Enquiry will work only if the process is in execution status, for a completed
process, enquiry will not show any output.
This screen shot shows the output of PROCESS.STATUS.VIEW enquiry, with 3

fields STATUS.MARKER, ACTIVITY.NAME and CONSTRUCT.
STATUS.MARKER : symbol indicating whether the process is running or

completed.
ACTIVITY.NAME : name of the activity which is executed and in execution.
CONSTRUCT : display the type of construct implemented in the process

(ROUTE.TO or PARALLEL.SPLIT or SWITCH)
When a user edits a record outside the process context, it is possible to check if
it is associated with PW. On completion of the edit, the next activity in the
process will be launched.
In case the user is not the owner of the record, an override is raised to
inform the user and the corresponding record will get completed. The
OVERRIDES will be stored in the activity txn record.
Launch Process CUSTACC.
Put CUSTOMER record on HOLD
Complete CUSTOMER record as USER who has privileges to execute activity
Next activity i.e. CREATE.ACCOUNT will be launched
Launch Process CUST.ACC. The first activity INPUT.CUSTOMER is displayed. Enter
some values and put record on HOLD.
Edit the CUSTOMER record which was put on HOLD and commit. PW recognises
that this is part of a workflow and launches the next activity INPUT.ACCOUNT.
When the INPUT.ACCOUNT is completed, the process is also completed
Process is started by CSAGENT. The CUSTOMER record is put on HOLD.
CUSTOMER record is now edited by AUTORISER (not belonging to BRANCH).
When record is committed, OVERRIDE is raised. The OVERRIDE is stored in the
PAT record.
The ENQUIRY shows that INPUT.CUSTOMER activity has been completed.
1. PW module does not have any built in business logic to create a Process Workflow.
•TRUE
•FALSE
2. In which application are all the activities combined in PW module?
•PW.PROCESS
•PW.PROCESS.DEFINITION
•PW.ACTIVITY
•PW.TRANSITION
3. In which application are all the activities defined in PW module?
•PW.PROCESS
•PW.PROCESS.DEFINITION
•PW.ACTIVITY
•PW.TRANSITION
4. How is the ID of PW.ACTIVITY formed?
•PW.VERB and PW.ACTIVITY.OBJECT
•PW.PROCESS.DEFINITION and PW.ACTIVITY.OBJECT
•PW.ACTIVITY and PW.STATUS
•PW.TRANSITION and PW.VERB
In this learning unit you have learnt about Process Workflow
You will now be able to

• State various applications involved in creating a workflow
• Create and execute the workflow

Ilide Info pw1 Setting Up A Workflow r17 PDF PR F58e679e4485b7f

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Ilide Info pw1 Setting Up A Workflow r17 PDF PR F58e679e4485b7f

Uploaded by

Copyright:

Available Formats

Welcome to ‘Setting up a Workflow in T24’ learning unit of the Process

Identify the applications involved in creating a workflow

Process is a series of actions or steps taken in order to achieve a particular end.

Lets discuss each of the applications

There is no business logic built into this application.

EVAL.CONDITION: This field is used in conjunction with the Loop (ROUTE.TO)

ACTIVITY.OWNER: Specifies the user(s) who is/are privileged to execute this

The ID of the record in this file is <application name>*<transaction reference

We will understand pattern based workflow in a later session

This screen shot shows the output of PROCESS.STATUS.VIEW enquiry, with 3

STATUS.MARKER : symbol indicating whether the process is running or

ACTIVITY.NAME : name of the activity which is executed and in execution.

CONSTRUCT : display the type of construct implemented in the process

You will now be able to

You might also like