Thursday, September 24, 2015

Screen Data Loading in Progress

Any Progress Programmer who has worked with the QAD ERP package is familiar with the "CIM format" of loading screens from specially formatted data files. I placed the phrase in quotes because although QAD can lay claim to the format they call CIM (originally an abbreviation for Computer Integrated Manufacturing) by enhancing this format to include deletion and enabling a batch mode system based on it, the format itself is native to standard Progress ABL functionality.

Many Progress Programmers who do not have familiarity with QAD do not know about this format for data loading. It's not like this format is necessary to load data into the database. It is sort of a strange format, and using it with a standard screen is a lot less straightforward than writing

create credit.
import delimiter "," account_code effect_date cr_amount.

which could load a table from a CSV file in short order. But the nice thing about using CIM format, or as I like to call it, Screen Data Loading format, is that
  1. you can very closely mimic the actions of someone entering or updating data via a Progress input screen,
  2. that way all input screen code can be reused and also 
  3. all referential integrity is maintained and
  4. the formatting is very similar to standard, delimited formats and just as readable.

To illustrate what I mean and how CIM format works, imagine you have a Progress program named mainmenu.p which is the main screen for an accounting system. This program brings up a credit input screen when you choose the code "CRINP". The input screen contains three fields and runs in a repeating block until END-ERROR is encountered (F4 in Unix, ESC in Windows). At this point a field labeled "Commit?" comes up and if the user types a "Y" then the program commits all the entered data into the credit database table and returns to the calling program.

Here's what a program would look like to use the Screen Data Loading format available in Progress for that screen:

/* Screen Data Loading (SDL) sample code */
input from sdl-credit.txt.
output to sdl-credit.log append.
run mainmenu.p.
output close.
input close.

The contents of a typical sdl-credit.txt would look like the following.

"2500" 05/25/14 1433.70
"5004" 05/26/14 500.00
- 05/24/14 100.00
"2500" 05/29/14 50.34

Here's what happens upon executing of the Screen Data Loading code:
  • CRINP would trigger the credit entry screen.
  • In the next 4 lines, the first field would go into account code, the second into date and the third into amount.
  • The single unquoted hyphen in the third input line cause the first field to be skipped over. This is especially useful to bypass unnecessary fields or to accept defaults in an input program.
  • The single period on a line designated and END-ERROR condition which brings up the "Commit?" question.
  • The "Y" commits the data and control is returned to mainmenu.p at which point the second period causes that program to exit.
  • All output is appended to the specified output log file. This file can get rather long since each input field causes the screen to be rewritten in its entirety, but it is good for trapping errors.
As I explained earlier, QAD deserves a lot of credit for utilizing this format in their own batch loading system, popularizing it, adding a method for deletion functionality and extensive error trapping and reporting. But I was gratified to learn that this method works on any system designed using Progress ABL. I used it for one client who owned a home-grown system without user-friendly input screens. Using the Screen Data Loading method I've outlined here, I was able to instruct users to fill out spreadsheets which then I transformed into the proper format and loaded into the system.

Once a programmer becomes familiar with the format, the part of the development which requires the most intense work is what I call the pre-validation of the data. For ongoing processes, I always make sure each of the fields being loaded will not flag an error ahead of time. For one-time data loads, I usually just "let 'er rip" and check out the error file after the fact. Of course one always needs to watch out for data values going into the wrong fields. But this danger exists in coding for more standard formats, so it is not a pitfall unique to this particular format.

Contact me for all your Progress/QAD Development requirements.

Phone: 216-496-9915

Tuesday, April 19, 2011

Streamserve: Utilizing Its Strengths

One of my favorite things about being a Streamserve Consultant is sometimes I get to do short, high-value projects. Most often, these mini-projects—which take less than a day to complete—involve implementing a formatting remedy for the sloppiness of the earlier design work. So aside from being able to fix these issues from the comfort of my office chair, the greatest aspect is the high customer satisfaction achieved.

The one I just finished is a prime example. Using a function in the PageOut, I concatenated multiple lines pulled from a StreamIN input which comprised the Terms and Conditions text. Then when it is output in an field configured as "Auto-wrap", it looks like someone typed it in using Microsoft Word rather than piped it in from a legacy ERP. That was how it looked before because basically the implementer pulled it in a pushed it out "as-is". Here's the short StreamServe scripting statement I used to make it look professional:
$t_and_c_fmt = subStrRepl($t_and_c, HexStr("<0A>"), " ");

I set the variable $t_and_c_fmt up and suppressed the output of the one which had been pulled in ($t_and_c). The subStrRepl function substitutes a space for newline characters. And that is pretty much all it takes, other than resizing the box correctly which was another part of the request.

In the midst of this project, I was asked a common question by the client. "Should we change the formatting of the text as we are sending it?" My answer was emphatically negative. Always use StreamServe for what it does best! You paid for it, and chances are that at least one person in upper management groaned at the price tag. Must people don't use StreamServe for even one fourth of what it is capable of doing. A good example of that will probably be my next project which involves Streamserve SMS implementation. You did know Streamserve did text messages, didn't you?

Contact us for all your StreamServe Consulting needs.
Phone: 216-496-9915

Monday, February 07, 2011

Point of Sale Systems Integration

I've often wanted to do systems integration work on Point of Sale (POS) systems and I've finally been given a chance on a short term project. A common POS system used by a bistro chain needs to be wired for a third-party program and, since the system is Progress-based, I was chosen to do the work.

So far there have been a number of challenges appear, but nothing entirely prohibitive. The POS uses Progress's cheapest product available, Personal Database, which is the bare-bones Progress run-time engine. This product alone doesn't allow compilation of normal Progress 4GL code, a development license is required to do that. I don't have a version 9 license, but fortunately there is a "trick" which I'll explain.

You can use a Run-time version of the prowin32.exe executable to compile code encrypted using Progress's source encryption program. This program is not probably not going to be included in a Progress Personal Database install, so you are going to have to find it somewhere else. I have it as a holder of a Progress OpenEdge OE Studio 10.0A license, so that's how I get stuff to compile. The logic hasn't changed between versions 9 and 10 and has never been altered since its inception as far as I know.

This is 100% legal in terms of Progress licensing and has been used as a backdoor for developers since I learned it back in 1994 using Progress RDBMS Version 6. It even works across platforms, and a file encrypted on a Windows PC will compile on an AIX, Linux or other Unix system with a run-time version of the Progress executable (_progres). Just remember that wherever you encrypt your code, the ensuing file is binary so you don't want to use ASCII mode when transferring it using FTP. That's usually trouble-shooting tip #1 in my experience when the code won't compile.

If you would like to know more about how to accomplish POS system integration with Progress when source is not available, please contact us for a quote. We can handle all your Progress DBA and Progress Programming needs.
Phone: 216-496-9915