3 replies to this topic

[Anorton]

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

[Vol Yip]

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,

I assume most of the time the Unix script runs seamlessly and it triggers all the functions (PRP, WO creation, WO completion, SO commit, create pack, confirm pack / ship and Bill). What you want is to have a way to analysis should any problem happen.

When you execute your Unix script to run all these screen transactions, I think you can direct all the screen output to a error text file?

For example, if your Unix script is abc.sh

abc.sh > abc.txt

should capture all the running results in abc.txt

Is that help?

Regards,

Vol

[Mark Snowshall]

We run numerous updates and reports under cron on unix and direct screen output to files by doing the above but adding 2>&1 to the end of the cron line.

Example;
/system/scripts/run_this_script.sh > /system/logs/run_this_script.log 2>&1

It throws out all characters sent to the screen including control characters that move the cursor around the screen etc but you can normally see enough when checking for errors. It's also worth putting UMSG's in certain places in your functions at the start to help.

[Anorton]

We run numerous updates and reports under cron on unix and direct screen output to files by doing the above but adding 2>&1 to the end of the cron line.

Example;
/system/scripts/run_this_script.sh > /system/logs/run_this_script.log 2>&1

It throws out all characters sent to the screen including control characters that move the cursor around the screen etc but you can normally see enough when checking for errors. It's also worth putting UMSG's in certain places in your functions at the start to help.

Thanks both Vol & Mark.

We are doing this much.

I think the problem may be that my question is application specific, rather than PROIV specific. I am working with Glovia, and Glovia has a type of error message, SLERR - these messages are not sent to the screen like a UMSG or MSG. They are viewed in a separate warning or error window.

These messages must be written to a temporary table, but are cleared when exiting the screen, I need to find where these are being stored. If there are any other Glovia developers out there with input, thank you in advance!