DSI dcLink ND3Nnnn BSFNs and the COM error state back in DSI

[johndanter]

Hi folks,

I have a question on the dcLink ND3N bsfns available in E1 and how to set errors that when dcLink is returned to, it doesn't pop messages up on the barcode scanner screen.

I am writing my own custom NER that will be called via dcLink and am looking at how the errors are set.
Now I know they set the behaviour COM (or whatever it is using dcLINKSetUser(BD3NSETU.dcLINKSetUser) and then use JDE system functions to set errors as follows:
Set NER Error(BF szErrorMessageKey_EKEY, <None>)
Set NER Error(BF szErrorMessageKey_EKEY, <None>) (set to 2 for error 1 for warning)

My question is does anyone here know how dcLink interprets this COM error when it's set to either 1 for a warning or 2 for an error?

The issue I have is our DSI developer wants to be told there is an 'error' but doesn't want me to set the return to 2 as he thinks this forces messages to pop up on the barcode scanner screen


They don't want pop up user messages but do want to know something went wrong.

This is a a DSI dcLink question really, but I am hoping someone here has experienced this themselves.

Thanks

John

 

[nkuebelbeck]

I don't have DSI experience, but from what you are describing I would add an additional parameter to the Data Structure, either a CHAR field or DTAI with the error DD code. Instead of using the System function, set the DSTR

Then the consumer of that BSFN would need to know to check for the parameter before proceeding etc etc

 

[johndanter]

I don't have DSI experience, but from what you are describing I would add an additional parameter to the Data Structure, either a CHAR field or DTAI with the error DD code. Instead of using the System function, set the DSTR

Then the consumer of that BSFN would need to know to check for the parameter before proceeding etc etc

Hi mate,

I've already done that and that works fine.....however for ONE error message only.
When you have more than one, you're kind of stuck.

What you have described is the approach we've gone down for now, as when the E1 NER sets the COM error DSI suddenly goes dark and can't see any of the return parameters.
Bit shocking, if this is the case.

but yes, if I don't set the COM error and just populate the DSTR variables, he's happy and can make his own mind up

 

[nkuebelbeck]

Spit balling....

An idea would be to create a custom table and add errors to it and return some key to that table.

use a larger DD item and delimit it somehow (comma, pipe, etc etc)

 

[BOster]

If you don't mind using some C code the calling BSFN can use the following API calls (or call another BSFN to interrogate the error list) to get all the errors , clear the errors, iterate the errors and even re-throw the errors - whatever you need to do.

cloneServerErrorList
clearServerErrorList
destroyErrorList
setErrorBasedOnList
setErrorBasedOnListWithCallMap

 

[Remo Williams]

-Please ignore this post. Can't find the option to 'Delete' a post-

 

[Remo Williams]

Spit balling....

An idea would be to create a custom table and add errors to it and return some key to that table.

use a larger DD item and delimit it somehow (comma, pipe, etc etc)

Not sure what you mean by your last line, but yeah, a custom table to store the errors in should work. Use a session key (PEID+TCID for example; there's a BSFN that determines them for you, I don't know its name from memory) + LNID as Primary Key for your table; Store each error with a different LNID. You can determine PEID/TCID in the calling object, and pass those to your (custom copy of the) DC Link BSFN (So add PEID/TCID to the BSFN's DSTR). Upon return, you can check the table to see if errors were encountered, and take the appropriate action.

 

[johndanter]

Cheers folks

Yes it looks like a table is the way to go but is horrendous that DSI loses all track off all passed back parms from the E1 NEr if you trip the COM.

Bad bad bad design

 

[nkuebelbeck]

Cheers folks

Yes it looks like a table is the way to go but is horrendous that DSI loses all track off all passed back parms from the E1 NEr if you trip the COM.

Bad bad bad design

this does seem wrong is a lot of ways. contact their support?

 

[Remo Williams]

Cheers folks

Yes it looks like a table is the way to go but is horrendous that DSI loses all track off all passed back parms from the E1 NEr if you trip the COM.

Bad bad bad design

"trip the COM"?

 

[JMR]

What release of dcLINK are you running? If 7 or greater (and this may even be available in earlier releases. I just can't remember), there is an option on the API call (bsfn call) to show errors from the gun. This option is 'off' by default. The developer has to explicitly set this option for the system to automatically show errors to the user.

If you are on an earlier release than 7, I think there are 2 'error' branches for each API call... 1 for errors (return code = 2) and 1 for comm errors (communication errors). Release 7+ has just one error branch that may trigger for either return code = 2 or comm errors.

Either way, when developing BSFN's for DSI, you should always return 2 when the function fails. Honestly, I don't understand what your DSI guy is thinking, but you may want further clarification. It is so much easier to code BSFN calls in DSI when the function returns 2 for errors... just is. In fact, all the ND3N functions do.

I have been at sites where I am the DSI guy and not responsible for E1 code. I have had to use custom E1 functions and tried (hard) to get the E1 guys to adhere to a couple of very simple things to do in those functions to make life easier for me in DSI. One of those things is returning 2 if a true error is detected in the E1 code. If you're on a 7+ release, there is also a variable (@_LastErrorMessage) available to the DSI developer that is a concatenation of all error codes set during the call to your E1 function. If the function returns 2, the 'Error' branch fires in the DSI code and the script can display that variable to show the error(s).

 

[silviayanez]

Hi,

I have a question. I add a new field in a standar app but I cant see.
The standar Apps have restriccions for see a new field??.

 

[johndanter]

Hi Jeremy,

Great reply thanks

A few questions for you though

What release of dcLINK are you running?

7. something

there is an option on the API call (bsfn call) to show errors from the gun. This option is 'off' by default. The developer has to explicitly set this option for the system to automatically show errors to the user.

Which developer? Me (E1 developer) or the other DSI guy?

Either way, when developing BSFN's for DSI, you should always return 2 when the function fails. Honestly, I don't understand what your DSI guy is thinking, but you may want further clarification. It is so much easier to code BSFN calls in DSI when the function returns 2 for errors... just is. In fact, all the ND3N functions do.

The issue is "failure" is subjective here. The guy designing this systems doesn't want the end user having a load of messages flip up on the screen all the time.
Things like a bad DB connection/lock are bad and yes the end user should know. But other things like a blank UOM etc, I've been told NO they don't need to know as it just slows them down.

I think this is being complicated further by the fact DSI isn't going to be the only consumer of my E1 BSFN NER. I'll wrap this in a BSSV and .NET applications will call it too. And they will want to know about ALL errors.

So I'm trying to make it a one stop shop and set errors as they occur and I hoped DSI would have the logic to carry on and not pop the message up when it encounters them.
Can you chose which errors pop up on the gun screen?
If so how?

So it's kind of a happy marriage between me ignoring certain errors and not setting return code 2 and

If you're on a 7+ release, there is also a variable (@_LastErrorMessage) available to the DSI developer that is a concatenation of all error codes set during the call to your E1 function. If the function returns 2, the 'Error' branch fires in the DSI code and the script can display that variable to show the error(s).

Yeah he's been playing with that and we have noticed that even a warning (return code 1) sets him on the error path.

 

[JMR]

Which developer? Me (E1 developer) or the other DSI guy?

The DSI guy. Automatic popping of errors from a BSFN call can be turned 'off' (actually is by default... they have to be explicitly turned 'on')

I think this is being complicated further by the fact DSI isn't going to be the only consumer of my E1 BSFN NER. I'll wrap this in a BSSV and .NET applications will call it too. And they will want to know about ALL errors.

That is a more difficult task and touched upon by other posters. You could write errors to a table that could then be downloaded and viewed on the device. That only works for new custom development and isn't a feasible solution for using any of the thousands of existing functions that currently exist, so I am not sure how that provides any sort of standard methodology for error handling on the devices.

So I'm trying to make it a one stop shop and set errors as they occur and I hoped DSI would have the logic to carry on and not pop the message up when it encounters them.
Can you chose which errors pop up on the gun screen?

Again, auto-popping of errors needs to be explicitly turned on. I, personally, have never used that option. I am not sure if it only shows errors when the return code is 1 and/or 2. You can have errors set in a BSFN call stack, but the function returns 0. In this case, I am not sure if the auto-popping feature would still show those errors.

One thing I've done in the past is write a SubApp (DSI guy will know what this is) that parses the @_LastErrorMessage variable into individual records and stored in an internal device table. Here is a sample of data from that variable after a bsfn call:

Return Code 2: . Error Code 3259: Error: Item Location not found Error Code 078M: Error: Open Cursor for cache I09UI002 failed Error Code 0678: Warning: Item Location Record Not Found Error Code 088R: Error: Blanks Invalid for Explanation . Error Code 078M: Error: Open Cursor for cache I09UI002 failed Error Code 0004: Error: Date Invalid or Missing

Have them write a routine that parses out the error code, error level (Warning/Error), and error text and write each entry to table on the device (they'll know what that means, too.) Then they can show what they want.

Yeah he's been playing with that and we have noticed that even a warning (return code 1) sets him on the error path.

That may be. I can't confirm that right now. That is ok... there is also a @_LastErrorCode variable that I believe would be the return code of the BSFN. Only perform error processing if that variable = 2.

My personal recommendation is for you to code your E1 function the way E1 intends. If the function throws errors that are fatal to the success of the process, return 2. I think it's much easier on the DSI-side to know the return code. If you always return 0, it puts so much onus on the developer of the script to know what all the possible error conditions are and how they should be handled. Too much work! And not very flexible. I want to know if the function fails. Then I can implement some standard error handling to show the user.

Good luck

 

[silviayanez]

Hi,
I am changeing the tags in P4310 but i can´t to see my change.

Do you have any idea

 

[johndanter]

Jeremy, you are awesome

Thanks mate

 

[nkuebelbeck]

some standard jde BSFN will implement a cSuppressErrors member in the DSTR. If it's != 1 it uses the typical jdeErrorSet Api and the BSFN returns 2, if its set to 1, it returns 0 and the writes the error to the DSTR (again, limit 1 or delimited errors)