We have recently upgraded Tuxedo from 8.0 to 11g and SALT from 1.0 to 11g.
Using tpreturn with TPFAIL and a non-zero tpurcode used to return the following message to the client - "GWWS_CAT:1033: Internal Error. Fail to call Tuxedo Service 'XXXX'. Tuxedo returns 'Tuxedo error: TPESVCFAIL - application level service failure, tpurcode = nnnnnnnnn".
However, now it is returning "GWWS_CAT:1059: Internal Error. Tuxedo application service returns TPFAIL.", without any mention of tpurcode.
Is this difference in behaviour down to the Tuxedo & SALT upgrade?
What do I need to do to get tpurcode to the client that I didn't need to do before?
I suspect the issue here is that SALT 1.0 (actually 1.1 I think was the first released version) didn't have the ability to specify an error signature, i.e., what was supposed to be the contents of the buffer when an error was returned from the application. The service metadata repository now accepts specifying an errbuf keyword to specify the buffer type when an error is returned by the service. As well, there are new parameter level keyword values for the access keyword to allow specifying the parameter is contained in the error return.
But, the one thing I haven't been able to determine is whether you can get access to the tpurcode. I'll see what I can find out.
Oracle Tuxedo Chief Architect
Can you please do me a favor and raise a support case with Oracle customer support and ask that this be "fixed". Please explain that in post SALT 1.1 versions there is no way for a SOAP client to access the rcode returned by the Tuxedo service. This is clearly a regression and something that was missed in our efforts to provide SOAP fault support for incoming SOAP requests.