Working on ESS MSS implementation. Using form processing.
I am a beginner and know that this binding needs some help. Developing a workflow to approve requests with steps in the following order.
2 Import container steps with binding as follows:
Step 1.
&FORM_STANDARD& @0E\QAssign Value@ @9T\QGets data for...@ &FORM&
'AWDTP' @0E\QAssign Value@ @9T\QGets data for...@ &FORM_FIELD_NAME_1&
'EMPLOYEE_NAME' @0E\QAssign Value@ @9T\QGets data for...@ &FORM_FIELD_NAME_2&
'AWAMT' @0E\QAssign Value@ @9T\QGets data for...@ &FORM_FIELD_NAME_3&
---
&AWARDTYPECONDITION& @9S\QReceives data from...@ @0D\QAssign Value@ &FORM_FIELD_VALUE_1&
&EMPLOYEENAME& @9S\QReceives data from...@ @0D\QAssign Value@ &FORM_FIELD_VALUE_2&
&AWARDAMOUNT& @9S\QReceives data from...@ @0D\QAssign Value@ &FORM_FIELD_VALUE_3&
Step2.
&FORM_STANDARD& @0E\QAssign Value@ @9T\QGets data for...@ &FORM&
'AWUNIT' @0E\QAssign Value@ @9T\QGets data for...@ &FORM_FIELD_NAME_1&
'MATRIX_IND' @0E\QAssign Value@ @9T\QGets data for...@ &FORM_FIELD_NAME_2&
'MATRIX_SUB' @0E\QAssign Value@ @9T\QGets data for...@ &FORM_FIELD_NAME_3&
---
&UNITCONDITION& @9S\QReceives data from...@ @0D\QAssign Value@ &FORM_FIELD_VALUE_1&
&MATRIXNONMATRIXAWARD& @9S\QReceives data from...@ @0D\QAssign Value@ &FORM_FIELD_VALUE_2&
&MATRIXORIGINATED& @9S\QReceives data from...@ @0D\QAssign Value@ &FORM_FIELD_VALUE_3&
Step3.
This is a condition routing the request by award type and it functions properly:
Performance &AWARDTYPECONDITION& = 0001
Other &AWARDTYPECONDITION& = 0002 or &AWARDTYPECONDITION& = 0003 or &AWARDTYPECONDITION& = 0004
Time Off &AWARDTYPECONDITION& = 0005
Step4.
The condition before this step sends different mail notifications based on the type of the request. The 3 paths merge back to one here for an edit form step.
Standard task: TS17900100 - Process Form
Here starts the problem I believe (somewhere in the binding)
(Note - I don't believe that the 'Approve' is correct in going to the form scenario stage, but I am not sure what to do here)
'X' @0E\QAssign Value@ @9T\QGets data for...@ &BACK_BUTTON_VISIBLE&
&FORM_STANDARD& @0E\QAssign Value@ @9T\QGets data for...@ &FORM&
'X' @0E\QAssign Value@ @9T\QGets data for...@ &SAVE_DRAFT_BUTTON_VISIBLE&
'HRASRB' @0E\QAssign Value@ @9T\QGets data for...@ &PROCESSOR_ROLE&
'X' @0E\QAssign Value@ @9T\QGets data for...@ &FORM.SUPPRESS_SAVE&
'00000' @0E\QAssign Value@ @9T\QGets data for...@ &FORM.FORM_SCENARIO_VERSION&
'APPROVE' @0E\QAssign Value@ @9T\QGets data for...@ &FORM_SCENARIO_STAGE&
---
&WORKITEM_ID& @9S\QReceives data from...@ @0D\QAssign Value@ &STEP_OBJECT.GUID&
&PROCSTATE& @9S\QReceives data from...@ @0D\QAssign Value@ &PROCSTATE&
Step 5.
This step is a manager approval.
Standard task: TS17900101
'X' @0E\QAssign Value@ @9T\QGets data for...@ &BACK_BUTTON_VISIBLE&
&FORM_STANDARD& @0E\QAssign Value@ @9T\QGets data for...@ &FORM&
'APPROVED' @0E\QAssign Value@ @9T\QGets data for...@ &FORM_SCENARIO_STAGE&
'X' @0E\QAssign Value@ @9T\QGets data for...@ &SAVE_DRAFT_BUTTON_VISIBLE&
'HRASRB' @0E\QAssign Value@ @9T\QGets data for...@ &PROCESSOR_ROLE&
&NOTIFY_VIA_MAIL& @0E\QAssign Value@ @9T\QGets data for...@ &NOTIFY_VIA_MAIL&
'X' @0E\QAssign Value@ @9T\QGets data for...@ &FORM.SUPPRESS_SAVE&
'00000' @0E\QAssign Value@ @9T\QGets data for...@ &FORM.FORM_SCENARIO_VERSION&
&SEND_VARIATION& @0E\QAssign Value@ @9T\QGets data for...@ &SEND_VARIATION&
---
Lower is same as previous step.
Step6.
Step 6 is a condition step based on the result of step 5. Binding is to the PROCSTATE container. This condition is failiing.
&PROCSTATE& = Approved
PROCSTATE is a container set to Structure: HRASR00_PROCESS_MODELLING and Field:PROCESSING_STATUS (approved is a possible value here.) the container properties are import and export.
It is difficult to follow your question with all these symbols. The more concise your question is the better chance you will get an answer. If there is no issue in the first 5 tasks, why even mention them in the question?
Hi,
What was the actual question?
The condition is failing, or? How is it failing? Even if you have value 'Approved', your condition does not take it into account? Have you checked the value of the container element in workflow log? Is it really 'Approved' or could it be perhaps APPROVED, etc.?
Please tell more details about the problem (not the previous steps that might have nothing to do with the problem).
Regards,
Karri
Your assumption of the question is correct. I check the container in WF log and see the approved status. The workflow condition editor automatically converts my constant value to Capitol letters. I need to check in the log again to see if the container is holding Capitol letters or lower case as well. I didn't know conditions were case sensitive. Could that have anything to do with the data type of the container holding my condition value?
Something else I noticed is that the workflow steps always say completed when they finish. It made me wonder if some setting could be in place to prevent the workflow from proceeding to the condition step after the approval step.
My gut feeling was that I have an issue with the binding though. Work items are available including PDF in the universal work list. I can approve. Other conditions work. Just this one reading from the procstate container isn't working.
Another thought I just had is that I thought the workflow condition usually takes the failed path if just the value in the container is incorrectly set/matched. I do not see the green progression bar going right into the condition/ not through it. Stops at the completed approval step.
OK; so it seems the problem is in the graphical log. This tool has some issue and is not accurate all the time. The more you work with it, the more you'll understand how it works. Sometimes, although the workflow instance would have already gone through the condition, you will still not see the green line if there was an error afterwards. So, double-click the condition step in the graphical editor and find out which path it took then check if the subsequent step failed and why it did fail. Using the "technical" log can help you there.