Parameterized URL

[wignat]

We are working on an upgrade to 9.1. I'm a BA putting together a demo for our users and have been reading about Parameterized URL. I'm a bit confused by the documentation and am looking for some real world scenarios for how this would be used that would make sense to our users.

For example the documentation refers to the Parameterized URL could be sent to another user (if the query is PUBLIC), like in an email, and the user could paste it into their browser and see the query. I get that, but if it is public access, can't they got to the application and access the query themselves?

Another part of the documentation says it "enables an external system to launch a native JDE E1 application....". Any scenarios here of "external systems" (maybe some external warehousing software, UPS package manifesting, etc?) Would be interested to see how others may have used this.

 

[Automation]

We used it for a screen pop when a customer rang up. We passed in the address book number into the P4210 screen.

 

[Rob Greven]

I have used parametrized URL's' in demos by creating 2 hyperlinks named "Enter Requisition" and "Receive Requistion" (both programs from the Requistion Self Service module) and putting them on a (simulated) Intranet page. This way 'once in a week' JD Edwards users can access JD Edwards directly from an intranet site without having to navigate the JD Edwards menus.

Regards,
Rob

 

[altquark]

Parameterized URL allows for a full-length URL to a specific transaction to be sent to an end user. When the user clicks on the URL, they are prompted for their E1 User ID and Password, and then provided the application PLUS the data for the specific transaction.

For example, its possible to send a specific sales order to a user with this method - the user clicks on the parametized URL and they jump immediately to the Sales Order Entry screen, populated with the Sales Order that was sent.

This is extremely valuable functionality specifically with workflow processing. If, for example, a voucher is entered into the system and then needs to be approved by a manager, then not only is it possible to send an email to a manager stating "Voucher needs approval" - but the parametized URL can be sent too, allowing the manager to just jump straight into the data rather than having to search for the data to approve.

JDE Workflow is very restrictive, and is certainly seemingly being phased out, in favor of other workflow systems - such as Oracle BPEL (SOA Suite) Workflow. By externalizing workflow, then workflow can be set up for much more than just JDE - such as product lifecycle, HR systems, warehouse management, etc etc. As such, JDE is perfectly set up for this type of external workflow system now since a parametized URL can be generated for a specific type of transaction together with a specific record.

A real-world example of the use of external workflow would be a product lifecycle implementation - such as Teamcenter or Agile, that sends item information through to JDE using an interface, then sends an email to the cost-accountant requesting that the cost information and other financial information be applied to the new item in JDE. Because a parametized URL is predictable, even an external system can work out what the URL should be with just the name of the Item Master program together with the internally generated Item Number that might be passed back as part of a Business Service call through SOA !

Remember, this only provides the link to E1 and the data. It still requires the user to have authentication access to E1 and have authentication occur !

 

[wignat]

Thanks. that is helpful. I assume when you say "customer Rang up" you are using call routing software to pop the screen for the person getting the call?

 

[wignat]

Very, very helpful. I appreciate your examples and details! I'm starting to get my arms around this.

Thanks again,
Tom

 

[Alex_Pastuhov]

Just wanted to mention on the Authentication point that with our SSO approach (which supports parameterized URL's), it would just transparently take the user, already signed in in the background without any additional prompts, straight to the target application with the transaction already open ;-)

 

[jdel6654]

One thing we did with parameterized URLs is to set up the cookie settings in JAS so that the id and password are valid for X days. In our case that was 30 days. So the users that rarely / reluctantly agreed to use E1, could skip the login process completely when they used the parameterized URL.

If / when the password needed to be updated, an E1 login screen would show up instead of the E1 app.

 

[Automation]

Yes, when the customer rang up after the call was routed through our ACD to a Customer Service operator, we passed in the phone number from the Call Routing software into a Visual Basic exe. This visual basic exe tried to find a matching phone number in the Who's who, then called a parameterised URL.

Here is an example of what we did, except this one works for Myriad IT's public JDE 9.1 environment. (Cudos to upgradejde.com for the public 9.1 environment and to support doc E1: JAS: How to Include User Login Credentials in a URL [ID 796704.1])

You can generate a sample parameterised URL in Tools 9.1 forms, by going into the Tools exit, then clicking Parameterised URL.



http://e1web.myriad-it.com:9088/jde/ShortcutLauncher?User=myr_demo&Password=demopwd&OID=P4210_W4210E_ZJDE0001&FormDSTmpl=|8|9|10|13|14|15|17|&FormDSData=|||||||4242|&FormQueryId=70a94e1a-aa6e-4fc6-8733-2863e76f6a1b


key to parameters on P4210 screen is the sequence number on the form, which can be found by going into OMW and using the form designer or by trial and error:
8 is SDDOCO
9 is SDDCTO
10 is SDKCOO
13 is customer purchase order
14 is SDLITM
15 is SDMCU
17 is SDAN8


Including the UserID and Password in the url is not a good idea, unless it is for a generic login that everyone already knows the password for.

 

[apndy]

@jdel6654
How to set up the cookie settings in JAS so that the id and password are valid for X days? Please advise.