Customer requested an option to not reject data received going to un-named LPD queues so a single LPD input (un-named queues) can process the data in a generic process.
I added the suggestion to an existing ticket, we have other improvements planned for the LPD Input, so we might as well take a look while we’re at it…
1 Like
They didn’t ask specifically for this, but how about the concept of a queue name mask where you could use a wildcard such as “LP_*” would grab “LP_1”, “LP_2”, etc.?
hmmmm… .for technical reasons that would be too painful to explain here, wildcards would be a lot more complex to implement. Part of the improvement to the LPD Input task already calls for multiple queue names inside a single input task (similar in that to the Folder Capture or HTTP Input tasks), and that would pretty much fulfill your request. You will just have to list all input queue names instead of using a wildcard, which I think is an acceptable compromise for now.
Sure that would still be a great addition
With 2020.2 , the ability to add multiple queues to LPD is there which is fantastic.
How does the empty queue names work?
Also is there a way to identify what the queue name was used within the process?
If not could it be populated into next available JobInfo[6] as a feature request
Unfortunately, the storing of the Queue name in a JobInfo didn’t make it in time for the release but will be included in the next one.
As for the empty queue name, well you simply tick the box and you then no longer have to specify a queue name when sending the job via LPR. Most LPR clients will not allow you to do that, but there are some that will, so that’s why this feature was implemented. Workflow’s own LPR Output can be used to test the feature.
The only thing you have to remember with empty queue names is that if you tick this option in a LPD Input, then you can’t tick it in another LPD input otherwise both processes will fight to process jobs received with empty queue names.
Great to hear that storing the queue name into a jobinfo is planned. This would help reducing nearly identical processes.
With the empty queue name will it allow a named, but not listed queue? In my example the Red, Blue and Green queues are listed, but the Yellow queue isn’t. The job to the Yellow queue was rejected, so I’m thinking not.
I’m not sure that it would be necessary except perhaps when initially setting up or capturing data phases. The fact that we can group LPD inputs together is huge.
I noticed that the queue list is maroon so it can take some dynamic elements. Is there a plan to support Global Variables?
No, you absolutely have to specify each queue name (including the “empty” queue name by ticking the option). The LPD input will only monitor those specific queues.
We hadn’t planned on supporting Global Variables, but as soon as you mentioned it I realized it could be helpful, especially when you use configuration files in startup processes. That would allow you to deploy the same process on different servers and simply change the configuration file so the LPR Queues would adapt accordingly.
I will add that to our database. Since we’re already fiddling with the JobInfos, might as well use the opportunity to support Global Variables!
2 Likes