Gary_Cherlet

Web Service Design Issue - Help wanted!!!

Discussion created by Gary_Cherlet on Jun 10, 2011
Latest reply on Jun 10, 2011 by Gary_Cherlet
I am seeking help on a design issue.
First, let me just mention, I have some but limited experience with Java and Web Services. I do have extensive experience with TCP/IP and other protocols, UNIX, and writing listeners. Oh! and IDMS for many, many, many years... I can't remember if Jon Gocher is older than me or not.
We have a system which currently runs in a batch mode on the UNIX side of the mainframe. There is a need to change this process to real time, which brings complications.

I'll attempt to describe the requirement
[color=#0627FF]First, if the process was purely manual from a user perspective the scenario would be:
1) At the appropriate time, identified by the user, while processing an ADS app, the user would start up a separate Internet Explorer session and enter a web site address (let's call it FP). (I cannot influence the design of the FP web site.)
The user is presented with icons for their specific type of work or a list of pending work to click.
2) If the user is presented with ICONS and clicks one of them, then the user is shown a window to be completed with a few defaults. I won't pursue this since it is the easy case and the user must continue on the site in a completely manual method.
[b]Here's the real design issue

If a pending work item is clicked, the web site returns a list of summary data of the chosen pending work items to the user. This is on a scrollable screen with many, many fields, where some fields are populated, some fields require data, and some fields can be skipped.
Here's the RUB - Some of these fields, if we could reach into IDMS could be populated automatically. Approximately, 35 fields that the user would not need to re-key.
The user enters data in the required fields. Some fields, when the single field is completed, may invoke a process that populates others from the FP site. (These Auto-populated trigger field(s) can filled from available IDMS data.)
Once all the data is entered, there are icons at the top of the form for the user to click to start the validation/finalization process.
1) Errors are presented at the top of the page.
2) Items that require data correction change color.
Users then enter into a SAVE DRAFT - VALIDATE process, which can be repeated until no errors appear.
Finally the user clicks on APPROVE
[ Note: by this time the user's IDMS session has timed out[/b] :sad
After clicking APPROVE - A new window appears with indication of SUCCESS.
Now the user would ALT-TAB or click on the lower tool bar to the IDMS mainframe session, "which has timed out".[color]

[b]Item that is not possible
The IDMS ADS online environment cannot communicate directly with a Web Service or "pop-up" a web page and communicate with it.
Two possibilities for automation were discussed with Dave Dillon (CA), when I had a general understanding of the process. Since I have gathered more information.
1) IDMS ADS can use TCP/IP to talk to a java listener running on another server (mainframe UNIX). The listener would need to interact with all the requirements of the FP process (web service) described above and relay the communications between it and the ADS process. The ADS process would present its own ADS version of the information to the user. The ADS process would need to be enhanced to handle all situations presented to it from the FP web service through the listener. It may be possible to write the ADS process more generically and alleviate future changes as FP changes, but still thinking about that one. Regardless, the listener would need to always handle all FP data entry and validation situations.
2) Use a Screen Scraper to run "on top of" both ADS and FD web pages. The screen scraper could recognize particular labels and data entries on either site (ADS and FP). I'm thinking, the Screen Scraper may be able to auto-start the FP web site depending on an entry in the ADS app. It could also communicate, via TCP, with IDMS to gather database information to populate the FP web page, when appropriate.

Any large or small suggestions are appreciated. Thank you for your time.

Bruce Swist
[color=#0336FF]bruce.swist@navy.mil[color]

Outcomes