Reading Landmark Files in Portal Form

I've done this with PFI before and it was easy to do a DME lookup on the WFWORKUNIT table to see if an open WorkUnit existed before submitting it again.
For IPA, you can't do a DME lookup like you want, but you could build that into your IPA flow so that if a new WorkUnit was created to just End if it sees that
another WorkUnit already exists.

I'm trying to prevent it from even being created, but that approach might work. Thanks.

i'm confused...is it that PO20 lets users release multiple times, which in turn creates multiple workunits, OR, is it the custom code that's releasing & creating workunits. I'm confused because the client i'm currently working with is running delivered PO20, which won't let you release the same PO more than once...i had a Supply Chain owner test this for me. So, it sounds like the custom code is letting users bang away and create multiple work units.

If so, i would focus on changing THAT code to prevent the multiple workunits.

It's the custom javascript code within PO20.1 that in the before transaction does not let the "release" occur. Instead it creates and triggers a Process Flow. The actual status of the PO stays as "unreleased". In the flow once the approvals are completed, then the PO is released and final issued.

So yes, that was what I wanted was some way prior to triggering the flow to read the Landmark business class of pfiworkunit and see if there were any pending ones for the PO. Just don't know how to with javascript code to build the equivalent of a DME call.

as DW previously mentioned...there's no way to currently execute a Landmark query from within DS. It might be developed eventually, but with Infor trying to move everything to the Landmark platform, they're prob not going to spend the money/resources to build it...it would have to come from one of us.

I understand that you're triggering directly into IPA, HOWEVER...
if you were triggering the BPM service, which would in turn initiate the IPA service, then you could query WFWORKUNIT from within DS. If a work unit was found with those values, then throw an alert and prevent a new work unit from being released.

Couple things -

1. Are you sure querying a Landmark WorkUnit from Design Studio is even the best route to go?
If your DS view can trigger a Landmark query, it might be better to have the FLOW itself check for duplicates.
A simple SQL query node to check the WU tables and then send Reject itself if it finds a duplicate would be relatively trivial functionality to add.

That being said - it is possible to query that information from a URL to your landmark server. The real question is are you ready for the mess of JSON that would be returned?

Structuring the URL is tricky, it will take some time for me to refresh my memory on how to query via a [servlet] list call to the landmark environment. Ill get back to you on that.

Better (as in simpler) solutions would be-

1. When the user submits a PO, have the Javascript clear all the fields after submitting the PO once, and/or have JS disable the submit button temporarily,  and/or have an alert() popup that reads "Hey guy, you submitted your PO, stop clicking submit".

It sounds like you have a user feedback problem. 

If your user goes through the effort of resubmitting AFTER you clear the form... then as a Drill Sergeant once told me, "You can't fix stupid".

2. Have your IPA flow check to see if it's a duplicate from the same user. If the originator is the same and the fields are the same - have your flow send them an email saying "stop it".

 

Both of those solutions will spare you from needing to shoot an SSO request to the landmark server from an invisible iframe, have it return the JSON to the hidden iframe in your DS screen, and then need a mess of Javascript to parse the return results. EVEN IF you do this the way you're theorizing, and DON'T disable the submit (at least temporarily after each click) then in the lag time between when the landmark server results are checked & processed by Javascript, they would still be able to click submit half a dozen times and negate the DS check anyways.

 

Just my 2 pence.

 

-Peter

 

 

 

 

 

Terry, a simpler solution is to use one of the user fields on PO20 as a flag when a WU has been triggered. Have a script that checks if the flag is set to blank when no WU exists and trigger, or if the field has a value return an error message that a WU already exists

And BTW Terry, you can use web services to query or update LMK tables from the browser. It's not easy but is doable. Already done it.