Chained iterations (again...)
You'll find in attachment 2 flows: "AD OK" is a duplicate "AD KO" flow, minus one step as I deleted one SQL query iteration.
In "AD KO" workflow, step "Get groups informations" doesn't even send the request to my mysql server (nothing in logs) whereas in "AD OK", it's launched and request is sent correctly (as seen on mysql logs).
It seems that in KO version, return result isn't evaluated. IMHO, it looks like some context problem, but I can't determine it, and I don't know how to solve it.
Could someone please be kind enough to look at it ?
Thanks by advance.
Pretty much same advice as before; check the Assign From and Assign To fields on the operation, especially considering its the same type of operation you removed from the flow.
If you do a Debug Stop at the Get Groups Info step check the step context and make sure the fields are inheriting the values you think they should be.
Generally if you have a flow which works, and then you remove a step and it stops working, something about that step was doing something; especially if it is the same type of step.
edit: Just realised you're using the JDBC operations since you are connecting to mysql. I haven't used any of these ops myself (always connect to SQL db), however sometimes using the same iterative operation (in this case SQL Query which has 'More Items' and 'No More Items' in the same flow can cause issues due to how they store results in the session. If you are absolutely sure the inputs are being assigned correctly (and verified by debugging the step context) try putting the second query inside a sub-flow; this will ensure it gets it's own session memory to work with. Unfortunately I don't have a mysql database here to test.
Arghhhhhh. Exactly what I feared 😞
I did every test possible, and I checked every variables (global, flow, step). I effectively didn't found any clue so I must admit this is more an OO limitation/bug than an error in my flow.
Just a question: if this is a known bug, is a fix planned soon or late ?
Indeed, putting my second query in a workflow works like a charm, but this breaks the generic philosophy I tried to develop. Anyway, if I don't have choice, I gonna do it this way.
Yes; when something weird happens with a flow you develop and it's using iterative operations (like List Iterator or SQL Query as examples) try putting the second iteration in a subflow. It's amazing how many times this will fix the issue!
The problem could be fixed in a patch or one of the content packs, you would have to read the release notes. If it hasn't been you can always submit a ticket to Software Support and they should make a hotfix for the operation and include it in a new content pack. It has been done for the Xpath and LDAP operations in the past when people pointed out this issue.
I'm curious about your general development philosophy wanting to avoid subflows though; more and more I try to keep things self contained in my flows by using sub-flows.
Still, happy I could help 🙂
Well, regarding this bug, I don't think it's gonna be easy to fix, as problem might be caused by JDBC connector (part of HP OO) or mysql connector (downloaded from mysql website). Experience proved me that each actor will charge the other one.
No matter, I'll keep doing with it.
About my "philosophy" now: I consider that every sub-workflow should do as less as possible.
As an example, let's consider the need (that my case) of a new user joining an enterprise. This user shoulg get an AD account, and he also belongs to n services. In some company, this implies that user's belongs to n AD groups. But in others entreprises, it means for exemple that an email must be sent to each service director.
So IMHO, iteration must be a part of main workflow, not of sub-workflow. I want to be able tu use my sub-worflows in many flows. I think sub-workflow should be applicable to only ONE parameter. Main workflow is in charge of calling it as many times as needed, not just one.
Does it make sense ?
PS: Sorry for my imperfect english
Your English is fine 🙂
It hopefully wouldn't be that complicated to fix, especially since it works inside a subflow. Essentially each flow gets a unique session ID within the JRAS agent. Iteration operations need to store their results/iteration within this session; correctly configured operations will do it with a unique hash or identifier while incorrectly configured ones all attempt to use the same store.
So in this case the second JDBC SQL Query object accesses the same ongoing store of the first iteration and the code logic doesn't know how to handle this.
I mentioned the XPath Query operation had this same issue; the hotfix made each iterator store its value in a variable like <hash>_xpath where the hash was determined based on the step inputs.