Hi,
I am getting the below error, I have only made modification in SQL query in the workflow and not touched the variables still getting the error.
com.workpoint.common.exception.ScriptEngineException: com.workpoint.common.exception.ScriptEngineException: com.workpoint.common.exception.ScriptEngineException: Script Engine cannot perform operation for statement 2. Job User Data key 'DELAYED' was specified as an operand but that key was not found in the Job User Data
Its pretty hard to troubleshoot workflow errors without the workflow.
Is this a migrated workflow, if so what version was it last known to work on and what version and patch are you currently on?
I would expect this is a problem with the scope of the workflow variable. Variables may defined as Node, Job or Public. You may be setting the variable in one scope but trying to read it in workflow that is out of scope.
Hi Ian,
Thankyou for your reply. This is not a migrated workflow. The workflow was created in IDM long back and was working fine. The latest version of our system is 7.2.0
I had just updated the SQL queries without deleting/recreating any nodes or transitions. I have checked that in previous workflow if the job "DELAYED" was used as Alias but that is not the case. It is defined only as a variable. PFB the screenshots.
In the above screenshot, the Set Value node is being used where DELAYED variable is declared as True.
In the above screenshot in transition, the variable "DELAYED" is used as Job operand.
As per my understanding the variable is declared later and not as Job variable and it is treated as Operand before.
But this is the original setup of the workflow which was working fine from a long time. Now I have just changed the query in almost all the SQL nodes but it gets stuck in the first SQL node and throws the error stated above.
(I noted a support case 01669816 is also open for this issue.)
Hi Ian,
Yes I have opened a case yesterday to better understanding.
Hi Bhamrah,
there was a customer here who had a similar problem.
In that case, they had some old workflows in progress, never closed, that was using the old workflow configuration. The admin wasn't able to change the configuration (as you are doing) until the "stucking" work were completed/removed.
Can you check if other activities are running and using this workflow, try to conclude them and then modify the workflow?
Cheers,
Pasquale
Hi Pasquale,
There are change requests which are currently active using the previous configuration workflow.
Are you suggesting we must verify that the previous configuration workflow shouldn't be in use and then change the SQL queries? If yes, we cannot do that as the workflow runs for almost every rule violation.
Is there any other workaround for this.
Thanks.
Hi Bhamrah,
I mean, check if there are any activities that are RUNNING that "bad" workflow (not that they are simply configured to use it or enabled) or worse STALLED.
This, at least from one customer, had blocked the modification of a workflow.
Regards,
Pasquale
While there are some reported instances where some things can prevent an edit to a workflow in this instance I believe the customer is able to edit and save the workflow and the changes are taking affect. The design of the workflow is just such that it is generating this error.
I see that you have still not resolved this issue.
Since this is a legacy workflow created on a different version and migrated, it is possible there is some hidden inconsistency in one of the workflow nodes.
This would not identify the root cause of the failure but might allow you to continue.
I noted that the case for this issue is still open pending a resolution.
I understand this was resolved by declaring the variable in the workflow before using it.
I understand this was resolved by declaring the variable in the workflow before using it.