on 03-15-2012 5:59 PM
We developed a web dynpro java application which accesses some RFCs in the backend through adaptive RFC method. We deployed it to DEV and QA through NWDI and it works fine. When we transported it to PROD it is generating the following error.
Zgt_Waitlist is a type generated by one of the adaptive RFCs and it is present in the code which is deployed in production.
Any clues where to look?
Error trace:
com.sap.tc.webdynpro.services.exceptions.TypeNotFoundException: type extern:com.cgi.rtis.model.types.RTISMod:com.cgi.rtis.model.types.Zgt_Waitlist could not be loaded: com.sap.dictionary.runtime.DdException: Type com.cgi.rtis.model.types.Zgt_Waitlist does not exist
at com.sap.tc.webdynpro.services.datatypes.core.DataTypeBroker.getStructure(DataTypeBroker.java:323)
at com.sap.tc.webdynpro.progmodel.context.DataNodeInfo.doInit(DataNodeInfo.java:234)
at com.sap.tc.webdynpro.progmodel.context.NodeInfo.init(NodeInfo.java:671)
at com.sap.tc.webdynpro.progmodel.context.NodeInfo.init(NodeInfo.java:674)
at com.sap.tc.webdynpro.progmodel.context.NodeInfo.init(NodeInfo.java:674)
at com.sap.tc.webdynpro.progmodel.context.NodeInfo.init(NodeInfo.java:674)
at com.sap.tc.webdynpro.progmodel.context.Context.init(Context.java:40)
at com.sap.tc.webdynpro.progmodel.controller.Controller.init(Controller.java:199)
at com.sap.tc.webdynpro.clientserver.cal.ClientComponent.init(ClientComponent.java:430)
at com.sap.tc.webdynpro.clientserver.cal.ClientApplication.init(ClientApplication.java:362)
at com.sap.tc.webdynpro.clientserver.session.ApplicationSession.initApplication(ApplicationSession.java:783)
at com.sap.tc.webdynpro.clientserver.session.ApplicationSession.doProcessing(ApplicationSession.java:303)
at com.sap.tc.webdynpro.clientserver.session.ClientSession.doApplicationProcessingStandalone(ClientSession.java:741)
at com.sap.tc.webdynpro.clientserver.session.ClientSession.doApplicationProcessing(ClientSession.java:694)
at com.sap.tc.webdynpro.clientserver.session.ClientSession.doProcessing(ClientSession.java:253)
at com.sap.tc.webdynpro.clientserver.session.RequestManager.doProcessing(RequestManager.java:149)
at com.sap.tc.webdynpro.serverimpl.defaultimpl.DispatcherServlet.doContent(DispatcherServlet.java:62)
at com.sap.tc.webdynpro.serverimpl.defaultimpl.DispatcherServlet.doGet(DispatcherServlet.java:46)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at com.sap.engine.services.servlets_jsp.server.HttpHandlerImpl.runServlet(HttpHandlerImpl.java:401)
at com.sap.engine.services.servlets_jsp.server.HttpHandlerImpl.handleRequest(HttpHandlerImpl.java:266)
at com.sap.engine.services.httpserver.server.RequestAnalizer.startServlet(RequestAnalizer.java:386)
at com.sap.engine.services.httpserver.server.RequestAnalizer.startServlet(RequestAnalizer.java:364)
at com.sap.engine.services.httpserver.server.RequestAnalizer.invokeWebContainer(RequestAnalizer.java:1060)
at com.sap.engine.services.httpserver.server.RequestAnalizer.handle(RequestAnalizer.java:265)
at com.sap.engine.services.httpserver.server.Client.handle(Client.java:95)
at com.sap.engine.services.httpserver.server.Processor.request(Processor.java:175)
at com.sap.engine.core.service630.context.cluster.session.ApplicationSessionMessageListener.process(ApplicationSessionMessageListener.java:33)
at com.sap.engine.core.cluster.impl6.session.MessageRunner.run(MessageRunner.java:41)
at com.sap.engine.core.thread.impl3.ActionObject.run(ActionObject.java:37)
at java.security.AccessController.doPrivileged(Native Method)
at com.sap.engine.core.thread.impl3.SingleThread.execute(SingleThread.java:104)
at com.sap.engine.core.thread.impl3.SingleThread.run(SingleThread.java:176)
Caused by: com.sap.dictionary.runtime.DdException: Type com.cgi.rtis.model.types.Zgt_Waitlist does not exist
at com.sap.dictionary.types.mdi.util.ProviderUtil.createAbapTypeXmlMap(ProviderUtil.java:400)
at com.sap.dictionary.runtime.mdi.DataProvider.createSimpleTypeFromAbapType(DataProvider.java:596)
at com.sap.dictionary.runtime.mdi.DataProvider.getDataType(DataProvider.java:296)
at com.sap.dictionary.runtime.DdDictionary.getDataType(DdDictionary.java:94)
at com.sap.dictionary.runtime.DdBroker.getDataType(DdBroker.java:164)
at com.sap.dictionary.runtime.DdBroker.getStructure(DdBroker.java:180)
at com.sap.tc.webdynpro.services.datatypes.core.DataTypeBroker.getStructure(DataTypeBroker.java:321)
... 33 more
Look to see in production that the RFC that you're calling is there, and also the associated datatypes. It looks like you may need to transport your latest backend transport for the RFC being called into production before running the application again.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi
1. Make sure your ABAP guys transported the RFC to prod.
2. RESTART your prod J2EE server!@!!
Regards
Yuval
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
The sub structures and data types of Zgt_Waitlist in prodcution R3 system is different from what you used while developing. Solution is to sit with your ABAPer and make sure that everything is same and is successfully transported to production in R3 side.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I'd say there are two possible problems here - either not all ABAP transports have been moved into your Prod ERP system or your Web Dynpro Metadata Cache needs clearing.
Usually, the second issue only occurs if the RFC is already in the system so would only be a problem for you if the RFC had already been in Prod and had been called via Web Dynpro adaptive RFC, then you had changed the interface signature and transported it through to Prod again. In this case, you need to use the invalidate Metadata cache tool available from the Web Dynpro console application. See here for info http://help.sap.com/saphelp_nw70ehp3/helpdata/EN/46/b1aa2f867762d7e10000000a1553f7/frameset.htm
Often, when I put a change control / transport procedure in place for new customers, I ensure there is a step in the process for the developer to confirm if there has been a change at the adaptive RFC layer and whether a simple server restart should be included as part of the maintenance slot for transports. This can be a bit heavy handed but is an alternative method of clearing the cache.
Hope this helps,
Gareth.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
84 | |
23 | |
11 | |
9 | |
8 | |
5 | |
5 | |
5 | |
5 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.