Process Model getting incorrect data from an Expression Rule

Hi Andrew,
Could you please check the following:

1. Verify the data types of the process variables being passed as inputs to the expression rule to ensure there is no mismatch.
2. Confirm that all values are properly passed to the inputs of sub-process B and that the process variables (parameters) have consistent data types.
3. Examine the process history of sub-process B to ensure it receives all the expected values from the parent model.

I hope one of the above points will help you identify the problem

Hi there.

Yes, the data types are correct, and there is no mismatch. All the values are properly passed into the inputs of the sub-processes, and have consistent data types. According to the process history, both sub-processes receive the expected values from the parent model. But the problem still persists.

Could you please share the process model and rule configuration screenshots to help debug this further?

My apologies, we found a resolution for this, and I forgot to post an update.

Hi andrewm231 ,
can you tell me what is the wrong because i have the same issues?

Could you pls tell us the resolution you found, thanks

when i call expression rule in script task, give me wrong results 
but in expression rule, give results as i expected?

Hi Nourhan,

Ah, the classic 'it works when I run it manually, but not when the script task does it'—it's like trying to explain to your team why the printer jams only during presentations!

If the expression rule behaves perfectly in isolation but throws a tantrum when called in a script task, here are a few things to check:

Inputs, Inputs, Inputs: Double-check if the script task is passing the same values you tested with. Sometimes, a tiny mismatch or a missing input sneaks in and causes all the drama.

Timing is Everything: If the script task is running alongside other nodes, ensure the data it needs is ready when it starts. Parallel processes love to race ahead before the data shows up to the party.

Log It Like It’s Hot: Add some logging to see what’s going into the rule and what’s coming out. It’s like setting up surveillance cameras for debugging—very handy!

Environment Mood Swings: Occasionally, process models seem to act differently depending on how they're triggered (manual vs. automated). Maybe the script task needs a pep talk?

Andrew, if you're reading this, we’re all curious about your resolution. Care to share the magic sauce? Nourhan, let us know if this helps or if there’s more to the mystery—happy to help crack it!

Yes, script task is running alongside user input task node to get its properties from report.
But i added timer until user input task is initiated!!

Ah, that makes sense now—thanks for clarifying! Running the script task alongside a user input task could indeed cause issues if the necessary data isn’t ready when the script task starts.

Your idea of adding a timer until the user input task is initiated is a smart workaround to avoid data timing issues. Just keep in mind:

Timer Duration: Make sure the delay is long enough to ensure all necessary data is available but not so long that it slows down your process unnecessarily.
Data Validation: If possible, add a check in your script task to confirm the data is populated before proceeding. This can act as a safeguard in case the timer doesn’t fully resolve timing issues.
It sounds like you’re on the right track—let us know if this completely resolves the issue or if you run into any more hiccups!"

Yes, i test in delay duration if this task is created in report then i found it
but after delay duration script task return nothing??

Hmm, that’s interesting. It sounds like even with the delay, the script task might not be picking up the data as expected. A few things you could check:

Timing vs. Data Availability: Is the user input task fully initiated and its data updated in the report by the time the script task runs? Sometimes, even after a delay, there could be a slight lag before the data becomes accessible in the report.

Test with Logs: Add some logging to your script task to capture exactly what it’s trying to read at that moment. This might give you clues on whether the data is there but not accessible or if something else is going wrong.

Check the Report’s Scope: Ensure that the report being queried includes the relevant context or process instance. If the script task is referencing a report tied to a different scope or filter, it might be missing the data.

Alternative Solution: If timing remains an issue, consider passing the required properties directly as process variables instead of relying on the report. This reduces dependencies and ensures the data is always accessible to the script task.

It seems like the issue is close to being solved—let us know if you find anything interesting in the logs or if we should brainstorm further!"

Hmm, that’s interesting. It sounds like even with the delay, the script task might not be picking up the data as expected. A few things you could check:

Timing vs. Data Availability: Is the user input task fully initiated and its data updated in the report by the time the script task runs? Sometimes, even after a delay, there could be a slight lag before the data becomes accessible in the report.

Test with Logs: Add some logging to your script task to capture exactly what it’s trying to read at that moment. This might give you clues on whether the data is there but not accessible or if something else is going wrong.

Check the Report’s Scope: Ensure that the report being queried includes the relevant context or process instance. If the script task is referencing a report tied to a different scope or filter, it might be missing the data.

Alternative Solution: If timing remains an issue, consider passing the required properties directly as process variables instead of relying on the report. This reduces dependencies and ensures the data is always accessible to the script task.

It seems like the issue is close to being solved—let us know if you find anything interesting in the logs or if we should brainstorm further!"