Retreive Error Message Desc from BSFN from NER

[BOster]

So calling on the server via Object Browser works but running via BSSV fails? What tools release are you on?

 

[nkuebelbeck]

So calling on the server via Object Browser works but running via BSSV fails? What tools release are you on?

That is correct, we are on tools release 9.1.4.6

I'm trying to wrap my head around this and see if I can prove it out, i think this might be a bug. I don't see very many bsfn that use the jdeErrorGetNextDDItemNameInfoEx API.

 

[nkuebelbeck]

would someone have time to try to import this par file and see if it kills kernels when executing the published business server method? (executing from the fat client should be good enough, no need to promote etc etc)

http://bit.ly/1z7rNPW

 

[BOster]

That is correct, we are on tools release 9.1.4.6

I'm trying to wrap my head around this and see if I can prove it out, i think this might be a bug. I don't see very many bsfn that use the jdeErrorGetNextDDItemNameInfoEx API.

Could be. Maybe when a BSFN is invoked via BSSV lpBhvrCom isn't filled out with what ever info is needed by jdeErrorGetNextDDItemNameInfoEx and jdeErrorGetNextDDItemNameInfoEx crashes.

 

[nkuebelbeck]

Could be. Maybe when a BSFN is invoked via BSSV lpBhvrCom isn't filled out with what ever info is needed by jdeErrorGetNextDDItemNameInfoEx and jdeErrorGetNextDDItemNameInfoEx crashes.

Did some digging and it appears that error messages are handled completed different with BSSV.

http://docs.oracle.com/cd/E24705_01/doc.91/e24219/create_bssv.htm#EOTME00032

the errors from the BSFN must exist elsewhere for the E1MessageList object to be able to access them :/

This makes things very difficult...

So I changed the below in JP555555
from
callF4211BeginDocWrapper(context, connection, internalVO);
to
messages = callF4211BeginDocWrapper(context, connection, internalVO);
and commented out the jdeErrorGetNextDDItemNameInfoEx code in the bsfn.
now the response from the BSSV includes the E1 error messages similar to what object browser displays.

Here is what the response xml looks like

<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">
<env:Header />
<env:Body>
<env:Fault>
<faultcode>env:Server</faultcode>
<faultstring>
CAUSE . . . . The number in the sold to field is not found in the address book.
RESOLUTION. . Enter a valid sold to address number on the ticket.

CAUSE . . . . The number in the ship to field is not found in the address book.
RESOLUTION. . Enter a valid ship to address number on the ticket.

</faultstring>
<detail>
<orac:BusinessServiceExceptionElement xmlns: orac="http://oracle.e1.bssv.JP555555/">
<orac:message>
CAUSE . . . . The number in the sold to field is not found in the address book.
RESOLUTION. . Enter a valid sold to address number on the ticket.

CAUSE . . . . The number in the ship to field is not found in the address book.
RESOLUTION. . Enter a valid ship to address number on the ticket.
</orac:message>
<orac:requestID>some ip address:51016:1418244910698:0</orac:requestID>
</orac:BusinessServiceExceptionElement>
</detail>
</env:Fault>
</env:Body>
</env:Envelope>

I'm assuming jdeErrorGetNextDDItemNameInfoEx hits a null pointer....

 

[BOster]

I'm assuming jdeErrorGetNextDDItemNameInfoEx hits a null pointer....

Probably a pretty good assumption.

In XML CallObject we also get a list of all the errors in the response XML. However, I am fairly certain I have BSFNs called via XML CallObject that interrogates the error stack using jdeErrorGetNextDDItemNameInfoEx and, depending on which errors it finds, executes logic. For example in the sales order module on a transfer order we have logic that looks for the error or warning that gets thrown when an item is not setup at a branch plant on a transfer order and finishes the item setup correctly (default JDE didnt set it up the way we wanted). But then again, maybe that branch of the code is just not executing on our various external systems that make calls via XML CallObject...

 

[nkuebelbeck]

Here is the how to get the error messages without using jdeErrorGetNexDDItemNameInfoEX inside the BSFN instead get the errors via BSSV....

E1MessageList messages = callF4211BeginDocWrapper(context, connection, internalVO);
//create the confirm VO from internal VO
D555555_Confirm confirmVO = new D555555_Confirm(internalVO);
if(messages.hasErrors()){
--E1Message list[] = messages.getE1Messages();
--for(int i = 0;i<list.length;i++){
----CallObjectErrorItem errorItem = list.getCallObjError();
----confirmVO.setLastErrorDesc(errorItem.getAlphaDescription());
----confirmVO.setLastErrorID(errorItem.getDDItem());
--}
confirmVO.setE1MessageList(messages);
}
finishPublishedMethod(context, "F4211BeginDocWrapper");

I'm going to open a case and see if this is working as designed (killing kernels that is) or if this is actually a bug.

 

[nkuebelbeck]

Oracle has thrown their hands up on this issue,because it's a custom BSFN and custom BSSV. Developers be warned.

 

[audioman]

Pardon for reviving this thread but...

How do you check the value of lpErrorStruct->lpszSubText or lpErrorStruct->lpszShortDesc if they are bad pointers? There are instances that lpErrorStruct->szDataItem is populated but these two are empty.

JDE E1 8.11 SP1
Tools Release 8.98

 

[nkuebelbeck]

DOES messages.getE1Messages() return anything?

 

[johndanter]

Yes. You obviously need to feed them all the way through

This is my internal project for exposing X0005
Feed in SY RT KY bring back DL01 DL02 and any error messages created in E1

Objects are J55X0005 and JPX0005 and messages are carried through in E1MessageList

 

[alan_007]

Here is a small little utility BSFN I wrote several years ago that will copy the current error stack to cache and let you iterate over the list. I use it quite a bit in UBEs to detect and display errors on a UBE as well as for situations like what you are talking about. I actually wrote an article in jdeTips on this if you have access to it it will explain a little more about how to use jdeErrorGetNextDDItemNameInfoEx and the attached BSFN as well as some "gotchas" with jdeErrorGetNextDDItemNameInfoEx.

what call stpe?

 

[johnd]

Hi Brian BOster

Do you have B59JDET1 as a par file at all please?

Thanks

John

 

[BOster]

I think I ported one of our utility BSFNs to that as an example or something so I don't believe I have that exact BSFN any more. Its pretty old, depending on what you are trying to accomplish there may be newer better ways. Even the underlying JDE C APIs I used back then have newer API replacements. I still use a utility BSFN for iterating the error list and output the errors in UBEs since UBEs do not display errors natively like APPLs do. But things like BSSVs, Orchestrations, etc. all have built in mechanisms for returning the error list.

What is it you are trying to accomplish?

 

[johnd]

I have a UBE that runs over F986110 and goes to F01131M etc and looks for errors. I then email them out if setup. I use the WC print UBe to do that,
So this would be great instead as it's giving errors in the job not errors in the WC

 

[BOster]

I have a utility BSFN that I do still use for this in your exact use case (show BSFN errors on the UBE) but there are dependencies in it to other utility objects we use here so to PAR it up would be bigger than what I could post here. I think the one I posted to this thread originally was a port of that utility to an example BSFN I did for something else. I no longer have the original BSFN I posted here (it would probably need some fixes anyway).

If you want to create it yourself the basic idea is three Function Calls (we preface all our custom BSFNs with "Acme", the name of our company):

AcmeGetErrorListInit - Copies all errors and error info to jdeCache
AcmeGetErrorListIter - Iterates the list of errors stored in jdeCache by AcmeGetErrorListInit
AcmeGetErrorListDestroy - Frees all resources allocated by AcmeGetErrorListInit (destroys the jdeCache)

Other Function you will need:

AcmeClearErrorList - Wrapper to jdeErrorClearEx. Clears the error list.  Needed in a UBE since a subsequent calls to AcmeGetErrorListInit would just return the same list of errors each time.

The key piece is obviously AcmeGetErrorListInit. Pseudo code for it:

jdeErrorSetToFirstEx - make sure the the error list pointer points to the first error
jdeErrorGetNextDDItemNameInfoEx - iterate through the errors, store info in jdeCache
jdeErrorSetToFirstEx - reset the list pointer to the first error

However, there are newer APIs. With these you would not need to use jdeCache, AcmeGetErrorListInit, AcmeGetErrorListIter and AcmeGetErrorListDestroy would just be wrappers.

New APIs:

cloneServerErrorList
jdeListGetFirst
jdeListGetNext
jdeListGetData
destroyErrorList

New Functions:

AcmeGetErrorListInit - cloneServerErrorList
AcmeGetErrorListIter - jdeListGetFirst, jdeListGetNext, jdeListGetData
AcmeGetErrorListDestroy - destroyErrorList