Get next item by key
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
01-04-22 10:07 AM
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:
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:
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
------------------------------
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.
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?
- 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!)
Paul, Sweden
(By all means, do not mark this as the best answer!)
4 REPLIES 4
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
01-04-22 11:14 AM
Hi Paul,
Just a suggestion, but this could be really slow.
I don't know how the ID from the customer or the insurance looks like, but when I need to compose a "multi key" with different ID I concatenate all with pipelines, this give me a fast way to search. Something like "[insuranceID]|[customerID]".
For search over the Queue... (and again, this is a suggestion of how i will resolve this problem)
If you get all the items in your ChildQ as Collection, then you can filter the collection with a like statement.
See you in the community, bye 🙂
------------------------------
Pablo Sarabia
Architect
Altamira Assets Management
Madrid
------------------------------
Just a suggestion, but this could be really slow.
I don't know how the ID from the customer or the insurance looks like, but when I need to compose a "multi key" with different ID I concatenate all with pipelines, this give me a fast way to search. Something like "[insuranceID]|[customerID]".
For search over the Queue... (and again, this is a suggestion of how i will resolve this problem)
If you get all the items in your ChildQ as Collection, then you can filter the collection with a like statement.
See you in the community, bye 🙂
------------------------------
Pablo Sarabia
Architect
Altamira Assets Management
Madrid
------------------------------
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
04-04-22 01:35 PM
Hi Pablo,
Thanks for your creative suggestion. This would indeed work nicely but also likely be, as you already mention, quite slow.
------------------------------
Happy coding!
Paul
Sweden
------------------------------
Thanks for your creative suggestion. This would indeed work nicely but also likely be, as you already mention, quite slow.
------------------------------
Happy coding!
Paul
Sweden
------------------------------
Happy coding!
Paul, Sweden
(By all means, do not mark this as the best answer!)
Paul, Sweden
(By all means, do not mark this as the best answer!)
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
04-04-22 06:33 PM
Hi Paul,
I check the official documentation, and I found something really interesting.
Exists a Web Service layer with specific methods to work with Queues. Here you have an action to search Items in the Queue.
Here you have the link: https://bpdocs.blueprism.com/bp-7-0/en-us/api-spec-7-0-1.html#tag/Work-Queues/paths/~1api~1v7~1workqueues/get
Basically, you can filter with a StartWith parameter. The syntax looks like this:
keyField[strtw]=Exa
So, you can put the keyField[strtw]=[ID insurance] + "|"
This is much cleaner than the search loop, but depends of your Blue Prism version.
Hope this helps you!!
See you in the community, bye 🙂
------------------------------
Pablo Sarabia
Architect
Altamira Assets Management
Madrid
------------------------------
I check the official documentation, and I found something really interesting.
Exists a Web Service layer with specific methods to work with Queues. Here you have an action to search Items in the Queue.
Here you have the link: https://bpdocs.blueprism.com/bp-7-0/en-us/api-spec-7-0-1.html#tag/Work-Queues/paths/~1api~1v7~1workqueues/get
Basically, you can filter with a StartWith parameter. The syntax looks like this:
keyField[strtw]=Exa
So, you can put the keyField[strtw]=[ID insurance] + "|"
This is much cleaner than the search loop, but depends of your Blue Prism version.
Hope this helps you!!
See you in the community, bye 🙂
------------------------------
Pablo Sarabia
Architect
Altamira Assets Management
Madrid
------------------------------
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
05-04-22 06:00 AM
Nice, thanks! We'll consider it when we get up to a newer BP version (6.5) than we run today.
------------------------------
Happy coding!
Paul
Sweden
------------------------------
------------------------------
Happy coding!
Paul
Sweden
------------------------------
Happy coding!
Paul, Sweden
(By all means, do not mark this as the best answer!)
Paul, Sweden
(By all means, do not mark this as the best answer!)
