Problem with ON_SAVE in Service Request

Question

Hi everybody.
I hope you can help me with this problem.
When i created a new Service Request and i went to another view, a pop-up is triggered with a cuestion asking if a want to save the view. If i choose yes, some AB lose the information when a come back to that Service Request. That is because the proccess don't pass in the ON_SAVE method and goes for another method.
Could you help me telling me a BADI or Component that cuold be executed when i click the Yes  button in the Pop-Up?
Thank you i n advance and regards.

Answer 1

vkalyanaraman wrote:
Thanks for the inputs.
Interesting thing that we have found out is, in the client code, till the control reaches the proxy class timestamp values is present in the request. But when the xml request is getting constructed(which we have logged in txt file by modifying clientconfig.xml) the date value is present but time value is getting droppedWell, that's expected surely?
You defined the element as a date in the XSD, so when the message is built it converts your Date into a date...ignoring any time stuff. That is what you asked it to do after all.
>
We had actually written the WSDL and had used axis2 eclipse plugin to generate request/response objects ,service & client stubs from itAh, that's good to hear.
Sorry for my rant...:)
>
As our WSDL is already in production, please let us know if we have some sort of work around, to modify the Webservice client code without going for WSDL change. It is also not possible to tamper the request objects as they are generated from WSDL and are packaged as jar file and placed in production
If in XML request, we are able to construct the time stamp, the service (generated from WSDL) is able to capture date time values. This was evident by constructing the timestamp request via SOAP UI / Lisa tool
Please adviseWithout maybe placing a Handler on the client side to take the built message and transform it (maybe), I can't think of anything upfront. That, however, would be a real hack.
Essentially, production or not, you have an incorrect WSDL which should be replaced. Someone there has allowed bad code into production. It happens, but to say "we can't change it"...well, put it this way, if it was a non-functioning bit of Java code (say a problem in a Servlet) would you be asking how to fix it without redeploying the application, or would you fix the code and redeploy?