The System Engineer Tool Belt and Problem Solving

Quite often, System Engineers are called upon to solve unusual problems. The greater our depth of knowledge about various technologies, the greater our problem solving ability.

My primary technology tool belt consists of knowledge in document capture, business workflow, enterprise content management, web development, .NET programming and web services, ERP Accounts Payable systems, and several other useful technology tools and systems.

Recently, a customer came to ImageSource with a problem. We had taught the customer how to use the PAWSER Oracle Imaging and Process Management (IPM) web SDK capability. What PAWSER makes possible is a specially constructed URL that can securely call an IPM system and retrieve a specific stored image. The P in PAWSER stands for “public” meaning there is no need for the calling user to log in to the imaging system.

For example, consider the following URL:

http://mywebserver/IBPMExpress/External/DocumentActionProcessor.aspx?ToolName=PAWSER&SearchName=APSEARCH&CheckDate=11/18/2009
&CheckNumber=0&VendorNum=1234567&Viewer=ImagingPlugin

URL explanation:

“APSEARCH”: This is the name of the Saved Search being queried in Oracle IPM
“CheckDate”: The field being searched
“CheckNumber”: The field being searched
“VendorNum”: The field being searched
“Viewer=ImagingPlugin”: This launches the IPM viewer

In this case, the customer was dynamically constructing this url in a J.D. Edwards WORLD ERP system to retrieve an image related to an invoice screen. The problem is that the WORLD environment only allows 123 maximum characters for the URL string. The required URL for the call has more characters than that.

So stop here, don’t look below. How would you solve the URL length problem?

Fortunately, my tool belt consists of web programming knowledge. After a bit of thought, I realized it would be trivial to create a custom .NET ASPX page that could contain the fixed string data in the URL, retrieve the desired parameters in a much smaller URL from WORLD, then build the final URL with all the bits, and redirect to the actual PAWSER target page.

The following C#.NET code snippet resides in the custom ASPX page and shows one way this can be accomplished.

string target =
@"http://mywebserver/IBPMExpress/External/DocumentActionProcessor.aspx?
ToolName=PAWSER";
string searchname = "&SearchName=APSEARCH";
string cd = Request.QueryString["cd"]; //check date
string cn= Request.QueryString["cn"]; //check number
string vn= Request.QueryString["vn"]; //vendor number
string qs= "&CheckDate=" + cd + "&CheckNumber=" + cn + "&VendorNum="
+ vn; //QueryString
string viewer = "&Viewer=ImagingPlugin";
string url = target + searchname + qs+ viewer;
Response.Redirect(url);

The code can be refined to be more elegant and efficient using StringBuilder and array parsing in the QueryString, but the above example demonstrates the general approach.

If we name the custom ASPX page, apsearch.aspx, then the much smaller dynamic url from WORLD becomes:

http://mywebserver/apsearch.aspx?cd=11/18/2009&cn=0&vn=1234567

You may have come up with a completely different solution, but we can only use the technology tools we have in our tool belt.

Clint Lewis
Senior Systems Engineer
ImageSource, Inc.

  

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s