Hi folks,
Here's something for y'all to ponder over during the weekend!
When reading the next item from a Q, your can either do just that: read the next item whatever it may be, or you can read the next item by some sort of key. This can either be by the exact value of the key, or by a value of the item tag, this last one is possible with a wildcard.
In my process, we have a parentQ containing customer ID and a childQ containing the customer's insurance IDs. The process reads the parentQ and then picks the insurances for this customer, puts them in the childQ and starts to process them by reading from the childQ and process each insurance ID.
Requirements:
- For reporting reasons, I do need the insurance ID in the childQ item key.
- For privacy and legal reasons, we cannot use any customer or insurance data in the item tag.
- For privacy and legal reasons, the item key is always encrypted.
We had this
solved previously by only loading one customer to the parentQ and that customers' insurances to the childQ and processing everything before start loading the next customer and its insurances to the Q. This is obviously not the way to go and, more importantly, does not allow parallell running of the process. We are reviewing this process to allow for parallell running.
As I need to read all insurances for the customer that is currently being processed, Id like to have the the combination of customer ID and insurance ID in the item key. However, BP cannot directly read a Q item based on part of the item key (the customer ID I'm currently processing) as this is not allowed in the get next item action. It only allows for the full item key value.
Intermediate solution:
While populating the childQ, I intend to build a list (collection) of insurances for this customer. When reading the childQ, I'll be using the next insurance ID from my list to do a direct read by key for the next insurance ID to process, thus avoiding that a parallell instance of the process will pick the wrong insurance.
Now for my questions:
BP:
- Why can't we read by item key with a wildcard?
- Why do we only have one item key instead of, say, two?
Community:
- Any suggestions on the above that would make my life a tad easier?
- Any showstoppers on my intermediate solution that you think are not gonna work?
Just a comment: Yes, this is a typical case of bad design haunting us. You probably can imagine that redesign of the complete process is not something this has made it to the top of our list of priorities... Hence my question------------------------------
Happy coding!
Paul
Sweden
------------------------------
Happy coding!
Paul, Sweden
(By all means, do not mark this as the best answer!)