This page (revision-54) was last changed on 26-Nov-2021 10:22 by Kevin Higgs

This page was created on 26-Nov-2021 10:22 by Administrator

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Page revision history

Version Date Modified Size Author Changes ... Change note
54 26-Nov-2021 10:22 12 KB Kevin Higgs to previous
53 26-Nov-2021 10:22 12 KB Meg McFarland to previous | to last
52 26-Nov-2021 10:22 12 KB Meg McFarland to previous | to last
51 26-Nov-2021 10:22 12 KB Meg McFarland to previous | to last
50 26-Nov-2021 10:22 12 KB Meg McFarland to previous | to last
49 26-Nov-2021 10:22 12 KB Meg McFarland to previous | to last
48 26-Nov-2021 10:22 12 KB Meg McFarland to previous | to last
47 26-Nov-2021 10:22 12 KB Meg McFarland to previous | to last
46 26-Nov-2021 10:22 12 KB Meg McFarland to previous | to last
45 26-Nov-2021 10:22 12 KB Meg McFarland to previous | to last
44 26-Nov-2021 10:22 12 KB kparrott to previous | to last
43 26-Nov-2021 10:22 12 KB kparrott to previous | to last
42 26-Nov-2021 10:22 12 KB kparrott to previous | to last
41 26-Nov-2021 10:22 12 KB kparrott to previous | to last

Page References

Incoming links Outgoing links
IMWA
IMWA

Version management

Difference between version and

At line 2 changed one line
!!!FUNCTION NAME
!!!DEFINE WORKFLOW ACTIONS
At line 13 changed one line
Please note that only the workflow actions that have a status of 'In Production' are available to be added to UserCalcs. BUT once they are included in a UserCalc just changing their status will NOT stop them from being used.
Please note that only the workflow actions that have a status of 'In Production' are available to be added to [UserCalcs]. BUT once they are included in a UserCalc just changing their status will NOT stop them from being used.
At line 21 changed one line
;Action Directed to|EVENT_RECIPIENT_TYPE]: This field stores values from a supplied lexicon and refers to the individual(s) to whom the workflow action is communicating. There are eight options to choose from: User, Employee, Manager, Business Contact, Candidate, Current Identity, Specific Identity and People List.
;[Action Directed to|EVENT_RECIPIENT_TYPE]: This field stores values from a supplied lexicon and refers to the individual(s) to whom the workflow action is communicating. There are eight options to choose from: User, Employee, Manager, Business Contact, Candidate, Current Identity, Specific Identity and People List.
At line 23 changed one line
With respect to emails, it is important to have set up the email addresses on the appropriate screens in order for the system to use the address when issuing the email.
%%information With respect to emails, it is important to have set up the email addresses on the appropriate screens in order for the system to use the address when issuing the email. %%
At line 25 changed one line
For both 'Employee' and 'Manager' these can only be used from tables with a hook to the P2K_HR_EMPLOYMENTS table.
For both 'Employee' and 'Manager' these can only be used from tables with a hook to the [P2K_HR_EMPLOYMENTS] table.
At line 29 changed 3 lines
* ''User' - If this recipient type is used, ensure that the User has been set up properly in IMUS with the email address stated there (for workflow actions that are issuing emails). If the email address on the IMUS record is blank then IF there is a person filled in on the IMUS record the system will try to retrieve the email address from the "Employee".
* ''Employee'', ''Manager'', ''Current Identity'' or ''Specific Identity'' - If one of these recipient types is used, then ensure that the email address is stated on the person's Prime assignment record (IEAS). When an email is issued and this recipient type is used, the system will go to the employee's IEAS screen and read the email address from there. If there is no email address on the employee's Prime assignment, the system will go to their Personal Information (IEPI) to retrieve the email address. If their IEPI record does not have an email address, no email will be sent.
* ''Business Contact'' - If this recipient type is used, ensure that the contact has been set up on IECI with the email address stated there. It is important that the business contact have a contact type value of "Business Contact" for their IECI record in order to select the contact as the recipient type in the usercalc.
* ''User' - If this recipient type is used, ensure that the User has been set up properly in IMUS with the email address stated there (for workflow actions that are issuing emails). If the email address on the [IMUS] record is blank then IF there is a person filled in on the IMUS record the system will try to retrieve the email address from the "Employee".
* ''Employee'', ''Manager'', ''Current Identity'' or ''Specific Identity'' - If one of these recipient types is used, then ensure that the email address is stated on the person's Prime assignment record ([IEAS]). When an email is issued and this recipient type is used, the system will go to the employee's IEAS screen and read the email address from there. If there is no email address on the employee's Prime assignment, the system will go to their Personal Information ([IEPI]) to retrieve the email address. If their [IEPI] record does not have an email address, no email will be sent.
* ''Business Contact'' - If this recipient type is used, ensure that the contact has been set up on [IECI] with the email address stated there. It is important that the business contact have a contact type value of "Business Contact" for their IECI record in order to select the contact as the recipient type in the usercalc.
At line 42 changed one line
|ODBC | Creates a list of subjects that an ODBC link could merge from. When this event media type is used, a record is created with ties to the following [views] in the database: [P2K_AM_VMWF_CONTACTS], [P2K_AM_VMWF_IDENTITIES] and [P2K_AM_VMWF_USERS]. These are views and the data within these can be reported on using Discoverer.
|ODBC | Creates a list of subjects that an ODBC link could merge from. When this event media type is used, a record is created with ties to the following [views] in the database: [P2K_AM_VMWF_CONTACTS], [P2K_AM_VMWF_IDENTITIES] and [P2K_AM_VMWF_USERS]. These are views and the data within these can be reported on using [Discoverer].
At line 60 changed one line
;Report Parm Set: The LOV contains a list of all parameter sets that were created. For example, if the Type is set to Reports and the report is for USPA, if a user has created a specific parameter set for USPA, then that parameter set can be specified.
;Report Parm Set: The LOV contains a list of all [parameter sets] that were created. For example, if the Type is set to Reports and the report is for USPA, if a user has created a specific parameter set for USPA, then that parameter set can be specified.
At line 68 changed 2 lines
!Section Headings within in each tab
;[FieldName]:Definition
The tab provides the user with the ability to enter an SQL select statement for the Completion Clause.
;[Text|EVENT_TEXT]:A completion clause is required in order to close the workflow loop. An SQL select statement can be entered here such that if the value in the select statement is returned, the workflow action is complete. If no value is returned, then the workflow action item remains incomplete. Note that the value is arbitrary BUT must be only 1 single value (or column).
The exceptions to this are found in the example of an email being sent. In this case, no completion clause is provided, yet the workflow action is marked with a status of 'Completed' or in the case of just wanting to launch a form or report.
SQL statements can be difficult to write therefore we recommend that a person with SQL knowledge along with familiarity of the various tables within the database be responsible for writing these statements.
When entering a 'Completion Clause' on IMWA, if the SQL script is invalid or has error the following message will be shown:
{{{
"Event Text Error = ORA-00942: table or view does not exist
ORA-06512: at P2k.P2k_SMREFCUR", line 8"
}}}
If you then press OK to this message, the record is saved. If this message should appear take the SQL script you are entering in IMWA and execute it in SQLPlus to see if there are any errors. Once you have a clean SQL script, put this into the IMWA and then you will not receive the error messages previously noted.
To use a completion clause you only have one piece of information from the workflow log available to use and it MUST be used in the clause. That piece of information is the ID for the record that triggered the log to be written. For example, a completion clause for WF_RAP would need to use ":RAP_ID" in the completion clause.
{{{SELECT 1 FROM P2K_RE_APPLICATIONS WHERE ID = :RAP_ID AND APPLICATION_STATUS = '80'}}}
Due to changes in the Oracle9i Database, you can no longer specify "*" as the value in the select as in SELECT * FROM …. The value selected is arbitrary and not used for anything so it can be a column or a constant value BUT can only be a single value. For example:
{{{SELECT 1 FROM …}}}
will work in every completion clause.
At line 74 changed one line
!Section Headings within in each tab
The 'Logs' tab maintains a history of the workflow actions and also provides the user the ability to view the workflow action in more detail.
An important note to remember is that every time a workflow action event takes place, a log is created. Therefore, reviewing the 'Logs' tab will indicate how many times the action event was fired. It is also a good place to review for testing purposes to ensure that the workflow action actually took place.
%%warning This tab is for viewing purposes only; you may not edit the data.%%
At line 77 changed one line
[CLEANUP]
;[Status|ACTION_STATUS]: This field defines the status of the workflow action. The four options available from the lexicon are:
* Newly Entered - Indicates that the workflow action has been assigned but has not yet been completed.
* Completed - Indicates that the workflow action has been completed.
* Pending - Indicates that the workflow action is still waiting to be completed.
* Cancelled - Indicates that the workflow action has been cancelled.
;[Assigned on|ACTION_ASSIGNED_DATE]: This field indicates the date on which the event action was assigned. For example, if a candidate applied for a posting on February 1st then the workflow action event was fired at that moment. Therefore, in our example this is the date that will populate this field.
;[Due On|ACTION_DUE_DATE]: This field refers to the date that the workflow action will appear to the recipient either on their task list or email, etc.
;[Completed On|ACTION_COMPLETION_DATE]: Indicates the date on which the workflow action was completed.
;Assigned To: This field corresponds to the recipient of the workflow action.
;Additional Info: This field corresponds to the information stored in the 'Description' section of the usercalc.
;Reference Info: The information in this field is hard coded into the program. It is created and controlled by the application developers and not by the user. It was coded into the program to provide the user with the ability to look up certain basic information.
!!Work Flow Emails that cannot be sent
If an WF email can not be sent because either a FROM or TO email address can not be found or is invalid, the Work Flow log will now be marked as cancelled with the completed date filled in. This will prevent the system from repeatedly trying to process a WF Log that can not be processed.
This page (revision-54) was last changed on 26-Nov-2021 10:22 by Kevin HiggsTop