This is a redundant post, so I apologize, but I could not find how to change the topic on my post, and I wanted to include 'Glovia' - in hopes to draw in more of the Glovia crowd for my Glovia specific problem:

We are in the process of developing integrations with another system. We are using GAPI for the most part, and there are certain processes that we want automated in our system, once we receive the GAPI document.

For example, we receive a sales order message, which creates the sales order; we then want PRP to run immediately to generate a work order for the sales line, then we want to automatically commit parts to the work order, issue parts to the work order, complete the work order, ship the sales line, and forward the order to bill.

So, we decided that a good solution would be to have GAPI call a function which then executes a Unix script that executes the screen function for each process we want to automate (each process/function will have it's own script).

So, once the sales line is created by GAPI, GAPI calls and passes information to a Unix script which then basically runs the PRP process, just as though a user would.

We have one stumbling block, how do we capture any errors that occur while the Unix script executes the screen function?

If it is an error message that would normally display to the user, these are being captured in the log files, a bit messy, but they're there.

However, there are other types of errors/warnings (SLERRs) that occur in the application that can only be viewed by clicking on an error or warning icon - we aren't sure how to capture these.

We need to, so that if a transaction fails, we can determine why.

Appreciate any input!!!!!

Allison

I don't know Glovia but I'll put my 0.02 in in case it's any use. I am trying to be helpful (honest).

If I have understood your scenario correctly, what I don't understand is how you will detect there was some error icon and simulate a click on it.

As I understand it you are "screen scraping", presumably because there is no Bus-&-Task or other programmatic API to achieve what you want.

It's not clear to me if you have some "screen scraping" tool that will allow you to program the interaction with the screen functions. If you don't and assuming these are GUI screens then maybe you need to investigate in that direction?

For what it's worth, programmed UI interaction is what the standard(ish) Unix tool "expect" does, however I have not used it and it may well be strictly textual (not GUI). See http://www.manpagez.com/man/1/expect/

I haven't worked much with Unix Scripts, but I assume you are using Glovia 9 and above? SLERR is actually the same as error messages. They only convert to those Error and warning icons if the SLERR function is called in between two global logics : SLGUICPS() and SLGUICPE(). Basically, as long as the SLERR function is called after the SLGUICPS() has been called, then it will print to those Error and Warning Icons until SLGUICPE() is called.
So, I don't think this will be an issue...unless the SLERR is writing messages differently from MSG?

This is a redundant post, so I apologize, but I could not find how to change the topic on my post, and I wanted to include 'Glovia' - in hopes to draw in more of the Glovia crowd for my Glovia specific problem:

We are in the process of developing integrations with another system. We are using GAPI for the most part, and there are certain processes that we want automated in our system, once we receive the GAPI document.

For example, we receive a sales order message, which creates the sales order; we then want PRP to run immediately to generate a work order for the sales line, then we want to automatically commit parts to the work order, issue parts to the work order, complete the work order, ship the sales line, and forward the order to bill.

So, we decided that a good solution would be to have GAPI call a function which then executes a Unix script that executes the screen function for each process we want to automate (each process/function will have it's own script).

So, once the sales line is created by GAPI, GAPI calls and passes information to a Unix script which then basically runs the PRP process, just as though a user would.

We have one stumbling block, how do we capture any errors that occur while the Unix script executes the screen function?

If it is an error message that would normally display to the user, these are being captured in the log files, a bit messy, but they're there.

However, there are other types of errors/warnings (SLERRs) that occur in the application that can only be viewed by clicking on an error or warning icon - we aren't sure how to capture these.

We need to, so that if a transaction fails, we can determine why.

Appreciate any input!!!!!

Allison

Hi Allison,

Been quite a while since I used SL but here is something you can try as I seem to recall that the SLERRs are only the normal ProIV error messages.

1. Create a new ProIV user to run you bakcground tasks and set the Logon function to a new function to set the following system variables and then link to the function you want to (most likely done by XFERIN)
@RFUNCT (ProIV Error function link called when a system error occurs) = New_error_function (where New_error_function is a new function you will create later)
@DFUNCT (ProIV Default function link called when @LFUNCT = '') = New_error_function
@TFUNCT (ProIV timeout function link called when @TIMEOUT is reached) = New_error_function

2. In your UNIX script remove a pre-determined error file
eg: ERR_OUT=${HOME}/err_file.txt
rm -f $ERR_OUT
then call ProIV something like this 'pro New_OPR Company_code Function_to_link_to'

3. Create a new function lets call it 'New_error_function', this function will be called when any of the following occurs, system error, @LFUNCT = '' and at timeout. In this new function create the Error file which you specified in your UNIX script, I usually create this in the home directory of the user. You can create the file like this:
$$FILE = &$@~HOME + '/err_file.txt' - Please note you can access any of the UNIX environment vaiables within ProIV by using [email=""]'&$@~'[/email] + the UNIX environment variable name.
SYSF([email="&#@CREATE,$$FILE,0,2000"]&#@CREATE,$$FILE,0,2000[/email]) - Please not the 0 is normally the key length but in this case we will be creating an SEQ file and the 2000 is the record length. In your function capture the following system variables and write them out to the SEQ file:
@MSG - ProIV error message number max 3 numeric
@MSGTEXT - ProIV error text max 65 alphanumeric
@MSGARGS - ProIV error arguements max 65 alphanumeric
@SYSERR - System error message eg ORA-1234 max 20 alphanumeric
@SYSERRTXT - System error text max 65 alphanumeric
If you are running on a newer version of ProIV (6.0) or above then also check the following MKY files:
ERRHDR - Error header file
ERRDET - Error detail file
These files typically hold the SQL being processed at the time of the error.
The file defs for these are:
ERRHDR
AK @MEMERRSEQ Length 6 Sequence Number
A @MEMERRDATE Length 10 Date Error Occured
A @MEMERRTYPE Length 4 Error Type
A @MEMERRTIME Length 6 Time Error Occured
A @MEMERRCURRSYSERR Length 3 System Error Number
A @MEMERRFUNC Length 32 Function Which Errored
A @MEMERRCYCLE Length 2 Cycle Number
A @MEMERRCYCLENAME Length 32 Cycle Name
A @MEMERRLOGICNAME Length 32 Logic Number Or Global Logic Name
A @MEMERRFILENAME Length 32 Current File Name
A @MEMERRFILENUMBER Length 2 File Number In Cycle
A @MEMERRLOGICALPATH Length 40 File Logical Path
A @MEMERRFIELDTAGNAME Length 32 Field Tag Name

ERRDET
AK @MEMERRSEQ Length 6 Sequence Number
AK @MEMERRTXTSEQ Length 6 Sequence For Error Text
A @MEMERRTXT Length 250 Error Text

Write all this out into your error file and then exit ProIV via OFF.

4. In your UNIX script check for any error output like this:
if [ ! -f $ERR_OUT ]
then
echo 'ProIV Executed OK'
else
echo 'ProIV Errored'
strings $ERR_OUT
exit 1
fi

This will cause the UNIX script to fail and the output from you error file will be sent to the stdout.

Hope this helps,

Best Regards,

Kapoof.

Wow, thank you all for detailed feedback! The PROIV and Glovia community/resources are so limited, when I get really stumped, I rely on ProivRC, and have never been let down!

After reviewing the replies yesterday, we have had a Eureka moment!

It so happens we are on Glovia v9 (FYI), and discovered that if we were on v10, we could easily capture the SLERRs, because in v10, they are the same as MSGs - sent to the screen, and always in the same position (how nice). In v9 they are not, so we were given the feedback that what we wanted to do couldn't be done.

Now, for the creative workaround we have devised, inspired by your feedback. The mention of the two global logics spurred the birth of our deceptive solution. Those global logics will either send the error messages to the icons (which we can't readily get to), OR write them to BBERRORS, if it is an XML transaction. SO, we are fooling the system into believing this is an XML transaction (we do this by setting a session variable), which in turn results in the global logics writing the error messages to the BBERRORS table, where we can easily review them.

So, in the beginning of our script, we set the session variable that defines this as an XML transaction, then we call SLGUICPS, next we call our screen function to do the automatic processing we want, and finally at the end of the script we call the SLGUICPE. If there were SLERRs encountered during the transaction, they'll be in BBERRORS, otherwise they'll be in the log file.

Thanks much!!!

Onward, and upward..........

Allison

Out of curiosity, what is the session variable you set?