JCO vs aRFC

Hi all,
I want to implement communication between my web dynpro and an R3 backend system. I've done this before, but i'm wondering about the technique to use.
In the article "Effective Web Dynpro - Adaptive RFC Models" I found the following and i quote:
"SAP strongly recommends using the Adaptive RFC Adapter instead of implementing another technique for accessing RFCs based on the JCo communication layer."
Is it really better to use aRFC instead of using plain JCO code directly? (JCO.Function..getImportParameterList(), ... )
I think it is much more cleaner when using the plain JCO way instead of the aRFC way. With aRFC, even for a simple BAPI you receive lots of generated classes and i think it just looks messy.
Am i wrong when i think that plain JCO has also better performance than aRFC?
Kind regards,
J.

Joren,
So as long as i dont mind doing the low level JCO programming in which i specify the names for the parameters and structures and so on... there's nothing wrong with using JCO from Web Dynpro too. Maybe EC is a good way for going for the in between (between plain JCO and ugly model aRFC) aproach...
It depends what to call "ugly"
For me JCo is not the best API, it's hardly an OOP but rather C-style like. Though, not surprising, because it's in fact same libs for Java and C and you may use JCo from native applications developed in C or other languages.
The WS approach is needed because we need to call R3 from existing J2EE application and we dont need to write new code for calling a WS... I think that is the only advantage of a WS, you can call it from everywhere like just any other Web Service...
I'd rather try SAP-EC (it generates typed wrappers). Or JCA if you talk about J2EE applications (like EJB or WAR projects). Anyway, it's up to you -- the only thing to note is that A-RFC available only to WD applications.
Suppose i would still implement it with aRFC, what is the best way to do context binding here? Directly from view context to component context to model context? so the model context will be filled automatically...
Or is it better to do the fillin of the model context manually via an intermediate node in the component context?
Typically you create model nodes based on A-RFC in component controller, then uses these nodes from view controller via context mapping. Just to separate view and controller parts. By the way, try to right-click on your component (or component controller, I do not remeber exactly) and apply "Service" template. You'll be surprised how many code is autogenerated on your behalf
Valery Silaev
SaM Solutions
http://www.sam-solutions.net

Similar Messages

JCO vs ARFC vs Web Service vs EC

Hi all,
In our project we will be calling BAPI's in a R/3 backend system. I've allready done this through importing the BAPI's as a model in NWDS (aRFC) because it's the used method in the Web Dynpro tutorials.
Now i'm wondering. What's SAP's recommended method to communicate with a R/3 backend system? Everybody is talking about webservices these days... and webservices are also an option for calling BAPI's in R/3. But what is SAP's opinion about this? Do they recommend it? (webservices are the future)
What is recommended, what is better, what gives the most options (security, transaction management, ...) when i can choose from all methods for calling BAPI's in R/3? ( JCO, aRFC, EC, webservices)
Kinds regards,
J.

Hi,
First of all, I'm not SAP and I'm not an architect.
The choice between BAPI's (RFC's) or webservices depends your specific situation. In most cases it is easiest to use available RFC's or BAPI's when present. These contain the backend logic that will eventually be called, even when webservices are used (at least in most cases).
For that reason, there are people that promote usages of RFC's BAPI's because of performance reasons and/or speed of implementation.
However, the future promise of CAF where functional consultants can create their applications knotting webservices together assumes it may be desirable to 'webservice-enable' your technical infrastructure.
If you (plan to) use other SAP products it also may be desirable to use XI. With XI you can easily convert RFC's or BAPI's to webservices. Without XI, you will have to write your own webservices that implement a BAPI call through JCO. I would rate that as the least desirable way for accessing the backend.
I don't know much about the difference in technical possibilities of BAPI's and webservices, but I suspect the differences are slight if any.
Hope this is helpful.
Good luck,
Roelof

Notes on JCO,RFC and ARFC?

Hi,
I need information regarding JCO,RFC,ARFC.
wht the main use of this?
Reply ASAP.
Regards
kiran

hi,
JCO
SAP Java Connector (SAP JCo) is a middleware component that enables the development of SAP-compatible components and applications in Java. SAP JCo supports communication with the SAP Server in both directions: inbound calls (Java calls ABAP) and outbound calls (ABAP calls Java).
SAP JCo can be implemented with Desktop applications and with Web server applications.
SAP JCo is used as an integrated component in the following applications:
● SAP Business Connector, for communication with external Java applications
● in the Application Server, for connecting the integrated J2EE server with the ABAP environment.
SAP JCo can also be implemented as a standalone component, for example to establish communication with the SAP system for individual online (web) applications.
RFC
Communication between applications of different systems in the SAP environment includes connections between SAP systems as well as between SAP systems and non-SAP systems. Remote Function Call (RFC) is the standard SAP interface for communication between SAP systems. The RFC calls a function to be executed in a remote system.
ARFC
Asynchronous remote function calls (aRFCs) are similar to transactional RFCs, in that the user does not have to wait for their completion before continuing the calling dialog. There are three characteristics, however, that distinguish asynchronous RFCs from transactional RFCs:
When the caller starts an asynchronous RFC, the called server must be available to accept the request.
The parameters of asynchronous RFCs are not logged to the database, but sent directly to the server.
Asynchronous RFCs allow the user to carry on an interactive dialog with the remote system.
The calling program can receive results from the asynchronous RFC.
regards,
Kris

Mapping Logical Systems sap-wd-arfc-useSys

Hi all,
I saw many many threads about this issue because sometimes seems to work but it doesn´t works for me.
So far I did the following:
Configure 4 JCO´s:
SAP_R3_HumanResources
SAP_R3_HumanResources_Metadata
These two points to my Dev environment
SAP_R3_HumanResourcesQAS
SAP_R3_HumanResources_MetadataQAS
These two points to my Qas environment
For all this JCO´s I got a successfull ping and test.
Then, I put the sap-wd-arfc-useSys parameters like this:
http://server:port/webdynpro/dispatcher/sap.com/essarpdata/ZPer_Personal_AR?sap-wd-arfc-useSys=SAP_R3_HumanResourcesQAS:QAS&sap-wd-arfc-useSys=SAP_R3_HumanResources_MetadataQAS:QAS but this does not do anything.
In this link http://help.sap.com/saphelp_nw70/helpdata/en/af/84a34098022a54e10000000a1550b0/frameset.htm the parameter should be the SUFFIX_OF_MAPPED_SYSTEM is the system Id? the client? what should be?
Do you have any ideas of what could I be missing?
Regards,
Orlando Covault

Please use it as follows:
sap-wd-arfc-useSys=SAP_R3_HumanResources:QAS&sap-wd-arfc-useSys=SAP_R3_HumanResources_Metadata:QAS
It should be <Default System>:<Suffix of Mapped System>
Your default system is - SAP_R3_HumanResources
Mapped system is - SAP_R3_HumanResourcesQAS
So suffix of the mapped system is - QAS
Hope that explains it.
Check this doc (page 17) for more info:
http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/526bd490-0201-0010-038e-d3ff7eb1d16e?quicklink=index&overridelayout=true
- Shanti
Edited by: Shanti Mupkala on Mar 16, 2011 5:26 PM

Couldn't create jco client connection for logical system

Dear Experts,
we are facing a strange issue in our custom webdynpro java application, few of our portal users are getting the "couldn't create jco client connection for logical system" for Model Data JCO Destination. below are details
1. portal version 7.02 SP14 (we have recently updated to SP14 from SP02-- is this is causing the issue ?)
1.1. updated the NWDI track with SP14 SCA files as well as added latest WD Runtime SCA file deployed the applications to Production also.
2. above said exception is inconsistent and happening for only few users
3. ping and test of jco destinations are successfull in content administration as well as in SLD, destinations were added in the SLD system.
4. cleared the JCO ARFC meta data cache in webdynpro console
5. jco destinations are configured using uid/pwd, configured user is not locked active and tested in the backend by logging in with the same user.
6. restarted the portal server
even though, we are getting the above said exception for few of portal users randomly.
Please help me on this ASAP, as i am not getting any further help on this.
Thanks,
Ram.

Hello Ram,
Check the JCo Pool Configuration settings of your JCO Destination. This message normally comes when the maximum connections has been reached. Increase the "Maximum Connections" to some number depending on the usage. A good habit is to disconnect the jco connection after executing the same in your webdynpro code if you don't want it to be synchronous.
<ModelName>.modelInstance().disconnectIfAlive()
Hope this helps.
Regards
Vijay

Webdynpro JAVA call ARFC

Hi Friend
I created the "ZBEN_DEMO_RFC" RFC in IDS.
When Webdynpro Java call the "ZBEN_DEMO_RFC" get a error.
How to get a ARFC?
Regards
Ben

Hi Ben,
I think problem is related to autherization, please chekc the userID/password and check SSO ticket for authorization while defining a metadata JCO Destination.
You can trace error RFC_ERROR_SYSTEM_FAILURE exception, have a look at the dev_jrfc.trc files. These files are written by JRFC and can be found in the directories j2ee/cluster/server* of the J2EE Application Server Installation.
Refre this WDJ - Adaptive RFC Troubleshooting Guide:-
http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/d0019b1a-775f-2910-beb8-d81f27d0d8d0?quicklink=index&overridelayout=true
http://wiki.sdn.sap.com/wiki/display/EP/8EstablishSingleSignOnbetweenPortal%28frontend%29andESS6.0%28backend%29
Hope this may help you
Deepak!!!
Edited by: Deepak Arora on May 17, 2010 6:00 AM

ESS + JCO + Multiple backend support

XSS with multiple backends
Hi All, we have a portal running with the standard ESS business package u2013 we use the system for demo purposes, and would like to be able to connect to different backend systems u2013 depending on the user.
IE, user XX connects to system DP4 and user YY connects to system ID4 u2013 is this possible?
My own approach was:
I made 2 delta copies of the of the standard ESS role to two folders u2013 XX and YY
XX I didnu2019t change, and therefore it used the standard SAP_R3_HumanResources JCO connection, which points to system DP4.
Then in the folder YY, I changed the WebDynpro iView parameter to:
sap-wd-arfc-useSys=SAP_R3_HumanResources_MetaData:ID4&sap-wd-arfc-useSys=SAP_R3_HumanResources:ID4
and in the Webdynpro Content administrator I created these systems and called them:
SAP_R3_HumanResources_MetaDataID4 u2013 as the guide from sap descripes.
This did however not seem to work, as metadata was still readout from DP4 while application data was Read out from ID4.
Then I noticed that the application eg. WhoIsWho also refers to som additional applications, such as
Xssfpmutil and so on u2013 and they use the JCO: SAP_R3_SelfServiceGenerics, so I created a
SAP_R3_SelfServiceGenericsID4, and added this to the parameter string, so I know looks like:
sap-wd-arfc-useSys=SAP_R3_HumanResources_MetaData:ID4&sap-wd-arfc-useSys=SAP_R3_HumanResources:ID4&sap-wd-arfc-useSys=SAP_R3_SelfServiceGenerics:ID4&sap-wd-arfc-useSys=SAP_R3_SelfServiceGenerics_MetaData:ID4
But this doesnu2019t work, some of the data is still read from Dp4 instead of ID4
So my question is u2013 is it possible to use ESS with two backends, or is this not supported?
Help is MUCH appreciated
Br Ronni

Hi stuart!
I made two copies of the standard ESS role
ESS_XX and ESS_YY, and then i changed i iview parameters for each iview
(by breaking the deltalink in both roles),
giving them the following application parameter:
sap-wd-arfc-useSys=SAP_R3_HumanResources_MetaData:ID4&sap-wd-arfc-useSys=SAP_R3_HumanResources:ID4&sap-wd-arfc-useSys=SAP_R3_SelfServiceGenerics:ID4&sap-wd-arfc-useSys=SAP_R3_SelfServiceGenerics_MetaData:ID4
But the problem is that while the user YY gets modeldata form system YY the user gets metadata from system XX
(assuming he is created on system XX, if not we get an error).
so i guess the parameters somehow dont match.
Has anyone used the same portal for different backends with sucess?
Br Ronni

JCo Scenario with multiple Backend Systems

Hello @ all,
Is it possible to use multiple Jco destinations to multiple Backendsystems in one WD application?
The scenario is as following: I want to call different function modules on different SAP Backend systems?

Hi Mehmet
Alternatively you could try switching the destination through URL parameters
http://<Host-Name>:<Port-Nummer>/webdynpro/dispatcher/local/Example_Project/Example?sap-wd-arfc-useSys= WD_MODELDATA_DEST:SyB&sap-wd-arfc-useSys=WD_RFC_METADATA_DEST:
SyB
Check this link (I havent tried it though)
http://help.sap.com/saphelp_nw04/helpdata/en/f4/651741f163f023e10000000a155106/frameset.htm
Regards
Pran

Problem in switching JCOs

Hi,
I have a very peculiar situation out here :(. I have a single webndynpro application and need it to connect to multiple backends.
The DC structure is as follows:
1) DC_UTILS - this DC contains components that actually execute the model objects. It has its own SINGLE model that consists of proxy classes for many RFCs. At the time of creation, these model classes were created with JCOs, "WD_MODELDATA_ABC" and "WD_RFC_METADATA_ABC".
2) DC_FAP - This DC uses DC_UTILS. It contains the entire business logic and screen flow and calls methods exposed by DC_UTILS.
3) DC_RUN - This DC uses DC_FAP. It has an application called 'RunApp' that calls the "Window Interface View Controller" of a component within DC_FAP.
I have tried to add the "sap-wd-arfc-useSys" parameters in the URL and fire the application, 'RunApp'. I am doing this by adding the above parameters to the URL dynamically in the "onPlugDefault" event handler of RunApp's Window interface View Controller. But somehow, the classes within DC_UTILS seem to get executed BEFORE the "onPlugDefault" method of the Window Interface View Controller (and hence the model proxies are generated with the JCO that I had used at design time)... and hence JCO switching doesn't take place.
I tried the above method in a single DC that contains the model classes, business logic and execute methods and it worked absolutely fine. The problem arises when I start using one DC in another. Somehow, the used DC's model classes get initialized with the JCO names set at design time , EVEN BEFORE THE onPlugDefault of the Window Interface View Controller of the USING DC is called. Is there any method / event in the USING DC that is called BEFORE the classes in the USED DC are initialized ?
regards,
Navneet.

Hi,
I tried using caps for the password......it didnt work.
The parameters given are the same as in dev but i get this error when I ping the JCO created : "com.sap.mw.jco.JCO$Exception: (103) RFC_ERROR_LOGON_FAILURE: Name or password is incorrect."
Are there any priveleges which are needed for JCO creation to use the same userid/pwd in staging?
What could be the other possibility?
Please suggest.
Regards,
Rajani

How to pass the JCo destinations as URL params?

Hi,
I have requirement to pass my JCo names as Url Params.
jcoParam = "WD_ORD_RFC_METADATA_DEST:MNR "+" WD_ORD_MODELDATA_DEST:MNR";
how do I combine and sent to URL params
urlParameters.put("sap-wd-arfc-useSys",jcoParam);
I am passing like this but the URL will take one parameter
with one name but I need to pass the same parameter with diffrent Jco destination how to solve this please guide in this.
I need like this But
Url will take one parameter with sap-wd-arfc-useSys this name only the parameter sap-wd-arfc-useSys name is not taking once again .
sap-wd-arfc-useSys=WD_ORD_RFC_METADATA_DEST:MNR
& sap-wd-arfc-useSys=WD_ORD_MODELDATA_DEST:MNR
Any body suggest on this.
Thanks,
Lohi.

Hi Lohita,
The parameter sap-wd-arfc-useSys should be given in the iview properties in the Content Administrator. The portal will be able to read the parameters properly even when you repeat the parameters like
sap-wd-arfc-usesys = WD_ORD_RFC_METADATA_DEST:MNR & sap-wd-arfc-usesys = WD_ORD_MODELDATA_DEST:MNR in the iview properties.
You will not abe able to pass it from the application as we would be using HashMap to pass the url parameters.As far as i know there is no other parameter available for the same purpose. Try giving the same in the iview of that applicaiton, it will work.
Regards,
Sharadha

Passing parameters through Single JCo to different systems

I have created a web dynpro application and integrated into a portal, which access R/3 using a JCo destination and retrieves the data using a BAPI.
But I want to integrate the same application into another portal, which would access the different R/3 system having the same function module.
Is there any way for switching between two Jco destinations as the same application could be made to work for both the systems?
Please suggest me as I am stuck up with this issue.
Thanks for your response; the thing is the portals are sharing the same landscape.
Is there any other way to achieve switching of the JCO destinations even on the same landscape?
You have the same application but want to connect to different JCos.
I think you will be creating two WD iViews for the same application. In the application properties do the following:
Use the following url parameter to the application URI
sap-wd-arfc-useSys=<DEFAULT_SYSTEM>:<SUFFIX_OF_MAPPED_SYSTEM>
In the default system you can change your JCo destination name
Please suggest me .
Thanks
Lohi

Hi Mani,
Thanks for your response.
And one more problem we are facing.
Now our application needs to be deployed on different systems with different JCo connection names, for this we have passed a parameter Sap-wd-arfc-useSys in the URL defining the new Jco Connection name .
for example we have created the application on Jco connection name ABC_DEST and we have passed the parameter value ans ABC_DESTLHP in the URL.
This ABC_DESTLHP JCO Connection is defined on the that particular system where we have deployed the application.
It was working fine When we were using one application and one component But it is not working with case of two applications and two components.
We are using inter applciation navigation to pass the parameters from first application to second application.
The parameters being passed are captured from the URL and that is creating the problem as the URL is being changed dynamically when capturing the parameters.
So Please let us know is there any way we could define the Jco Connection name in the program itself.
Or else if you could provide me your number that would be great help (If you are in US or India) .
Thanks in advance
Lohi

Meta JCo connection issue - cannot have 2 systems for ESS????

I have a finance R/3 system and also an HR R/3 System.
I need to be able to use the FI system for the timesheet ESS screens and the HR system for the others. I have used the iView Application parameter as documented;
(sap-wd-arfc-useSys=SAP_R3_HumanResources:FIN&sap-wd-arfc-useSys=SAP_R3_HumanResources_MetaData:FIN)
The JCo destinations have been configured and do work ....
However the problem is that the meta data jco connection that is used first appears to be cached and is then used going forward for every subsequent screen.
Therefore if I leave the menu screens as they are by default my timesheet screen won't work because the meta connection has been opened to the HR system and therefore the meta and data connections now don't match - even though the parameter has been set as above the configuration is ignored.
I get the following error message
Caused by: com.sap.tc.webdynpro.services.exceptions.WDRuntimeException:
Accessing System DE7 is not possible because RFC Metadata was retrieved
using System DH7. Please assure you have configured the RFC Connections
properly. A Server restart may be necessary!
So if I change the menu to use the finance system then the timesheet screen will work but none of the HR screens will work. (same error with the systems reversed)
Is there any way of getting this to behave properly and make sure that the right Jco connection is used. It is very frustrating because the configuration is correct, I just need to be able to force the applications to use the the Jco destination that has been defined for the iView.
Regards
Marina

Hi, I have created new iview for Who's Who and put the below in Application Parameters:
sap-wd-arfc-useSys=SAP_R3_HumanResources:UTL&sap-wdarfc-useSys=SAP_R3_HumanResources_MetaData:UTL&sap-wd-arfc-useSys=WD_MODELDATA_DEST:UTL&sap-wd-arfc-useSys=WD_RFC_METADATA_DEST:UTL&sap-wd-arfc-useSys=SAP_R3_SelfServiceGenerics:UTL&sap-wd-arfc-useSys=SAP_R3_SelfServiceGenerics_MetaData:UTL
The Home Page Framework is working fine. but when clicking on the who's who service the below error is there:
The initial exception that caused the request to fail, was: java.lang.NullPointerException at com.sap.pcuigp.tracking.BTrackingComp.isValuePackSystem(BTrackingComp.java:290) at com.sap.pcuigp.tracking.BTrackingComp.onInit(BTrackingComp.java:206) at com.sap.pcuigp.tracking.wdp.InternalBTrackingComp.onInit(InternalBTrackingComp.java:173) at com.sap.pcuigp.tracking.BTrackingCompInterface.onInit(BTrackingCompInterface.java:115) at com.sap.pcuigp.tracking.wdp.InternalBTrackingCompInterface.onInit(InternalBTrackingCompInterface.java:124) ... 75 more See full exception chain for details. System Environment Client Web Dynpro Client Type HTML Client User agent Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30) Version null DOM version null Client Type msie7 Client Type Profile ie6 ActiveX enabled Cookies enabled Frames enabled Java Applets enabled JavaScript enabled Tables enabled VB Script enabled Server Web Dynpro Runtime Vendor: SAP, build ID: 7.0103.20081111115141.0000 (release=NW701_03_REL, buildtime=2008-12-07:13:19:14[UTC], changelist=51958, host=pwdfm246), build date: Mon Dec 20 02:32:06 CST 2010 J2EE Engine 7.01 PatchLevel 56102. Java VM IBM J9 VM, version:2.3, vendor: IBM Corporation Operating system AIX, version: 6.1, architecture: ppc64 Session & Other Session Locale en_US Time of Failure Wed Feb 09 14:56:21 CST 2011 (Java Time: 1297284981490) Web Dynpro Code Generation Infos sap.com/pb SapDictionaryGenerationCore 7.0103.20071003090459.0000 (release=701_SP_REL, buildtime=2008-11-05:19:55:10[UTC], changelist=463950, host=PWDFM201.wdf.sap.corp) SapDictionaryGenerationTemplates 7.0103.20071003090459.0000 (release=701_SP_REL, buildtime=2008-11-05:19:55:16[UTC], changelist=463950, host=PWDFM201.wdf.sap.corp) SapGenerationFrameworkCore 7.0103.20071003090713.0000 (release=701_SP_REL, buildtime=2008-11-05:19:48:07[UTC], changelist=463957, host=PWDFM201.wdf.sap.corp) SapIdeWebDynproCheckLayer 7.0103.20080730170941.0000 (release=701_SP_REL, buildtime=2008-11-05:20:00:15[UTC], changelist=494993, host=PWDFM201.wdf.sap.corp) SapMetamodelCommon 7.0103.20071003091208.0000 (release=701_SP_REL, buildtime=2008-11-05:19:48:51[UTC], changelist=463971, host=PWDFM201.wdf.sap.corp) SapMetamodelCore 7.0103.20071003091208.0000 (release=701_SP_REL, buildtime=2008-11-05:19:48:46[UTC], changelist=463971, host=PWDFM201.wdf.sap.corp) SapMetamodelDictionary 7.0103.20071003090530.0000 (release=701_SP_REL, buildtime=2008-11-05:19:52:58[UTC], changelist=463951, host=PWDFM201.wdf.sap.corp) SapMetamodelWebDynpro 7.0103.20080730170953.0000 (release=701_SP_REL, buildtime=2008-11-05:19:57:29[UTC], changelist=494995, host=PWDFM201.wdf.sap.corp) SapWebDynproGenerationCTemplates 7.0103.20081105123737.0000 (release=701_SP_REL, buildtime=2008-11-05:20:06:40[UTC], changelist=507414, host=pwdfm201) SapWebDynproGenerationCore 7.0103.20080730170941.0000 (release=701_SP_REL, buildtime=2008-11-05:20:00:20[UTC], changelist=494993, host=PWDFM201.wdf.sap.corp) SapWebDynproGenerationTemplates 7.0103.20081105123737.0000 (release=701_SP_REL, buildtime=2008-11-05:20:06:40[UTC], changelist=507414, host=pwdfm201) sap.com/tcwddispwda No information available null sap.com/pb_api SapDictionaryGenerationCore 7.0103.20071003090459.0000 (release=701_SP_REL, buildtime=2008-11-05:19:55:10[UTC], changelist=463950, host=PWDFM201.wdf.sap.corp) SapDictionaryGenerationTemplates 7.0103.20071003090459.0000 (release=701_SP_REL, buildtime=2008-11-05:19:55:16[UTC], changelist=463950, host=PWDFM201.wdf.sap.corp) SapGenerationFrameworkCore 7.0103.20071003090713.0000 (release=701_SP_REL, buildtime=2008-11-05:19:48:07[UTC], changelist=463957, host=PWDFM201.wdf.sap.corp) SapIdeWebDynproCheckLayer 7.0103.20080730170941.0000 (release=701_SP_REL, buildtime=2008-11-05:20:00:15[UTC], changelist=494993, host=PWDFM201.wdf.sap.corp) SapMetamodelCommon 7.0103.20071003091208.0000 (release=701_SP_REL, buildtime=2008-11-05:19:48:51[UTC], changelist=463971, host=PWDFM201.wdf.sap.corp) SapMetamodelCore 7.0103.20071003091208.0000 (release=701_SP_REL, buildtime=2008-11-05:19:48:46[UTC], changelist=463971, host=PWDFM201.wdf.sap.corp) SapMetamodelDictionary 7.0103.20071003090530.0000 (release=701_SP_REL, buildtime=2008-11-05:19:52:58[UTC], changelist=463951, host=PWDFM201.wdf.sap.corp) SapMetamodelWebDynpro 7.0103.20080730170953.0000 (release=701_SP_REL, buildtime=2008-11-05:19:57:29[UTC], changelist=494995, host=PWDFM201.wdf.sap.corp) SapWebDynproGenerationCTemplates 7.0103.20081105123737.0000 (release=701_SP_REL, buildtime=2008-11-05:20:06:40[UTC], changelist=507414, host=pwdfm201) SapWebDynproGenerationCore 7.0103.20080730170941.0000 (release=701_SP_REL, buildtime=2008-11-05:20:00:20[UTC], changelist=494993, host=PWDFM201.wdf.sap.corp) SapWebDynproGenerationTemplates 7.0103.20081105123737.0000 (release=701_SP_REL, buildtime=2008-11-05:20:06:40[UTC], changelist=507414, host=pwdfm201) sap.com/tcwdcorecomp No information available null Detailed Error Information Detailed Exception Chain java.lang.NullPointerException at com.sap.pcuigp.tracking.BTrackingComp.isValuePackSystem(BTrackingComp.java:290) at com.sap.pcuigp.tracking.BTrackingComp.onInit(BTrackingComp.java:206) at com.sap.pcuigp.tracking.wdp.InternalBTrackingComp.onInit(InternalBTrackingComp.java:173) at com.sap.pcuigp.tracking.BTrackingCompInterface.onInit(BTrackingCompInterface.java:115) at com.sap.pcuigp.tracking.wdp.InternalBTrackingCompInterface.onInit(InternalBTrackingCompInterface.java:124) at com.sap.pcuigp.tracking.wdp.InternalBTrackingCompInterface$External.onInit(InternalBTrackingCompInterface.java:198) at com.sap.pcuigp.xssfpm.wd.FPMComponent$FPM.attachComponentToUsage(FPMComponent.java:922) at com.sap.pcuigp.xssfpm.wd.FPMComponent$FPM.attachComponentToUsage(FPMComponent.java:891) at com.sap.pcuigp.xssfpm.wd.FPMComponent$FPMProxy.attachComponentToUsage(FPMComponent.java:1084) at com.sap.pcuigp.xssutils.pernr.FcEmployeeServices.onInit(FcEmployeeServices.java:219) at com.sap.pcuigp.xssutils.pernr.wdp.InternalFcEmployeeServices.onInit(InternalFcEmployeeServices.java:273) at com.sap.pcuigp.xssutils.pernr.FcEmployeeServicesInterface.onInit(FcEmployeeServicesInterface.java:135) at com.sap.pcuigp.xssutils.pernr.wdp.InternalFcEmployeeServicesInterface.onInit(InternalFcEmployeeServicesInterface.java:198) at com.sap.pcuigp.xssutils.pernr.wdp.InternalFcEmployeeServicesInterface$External.onInit(InternalFcEmployeeServicesInterface.java:258) at com.sap.pcuigp.xssfpm.wd.FPMComponent$FPM.attachComponentToUsage(FPMComponent.java:922) at com.sap.pcuigp.xssfpm.wd.FPMComponent$FPM.attachComponentToUsage(FPMComponent.java:891) at com.sap.pcuigp.xssfpm.wd.FPMComponent$FPMProxy.attachComponentToUsage(FPMComponent.java:1084) at com.sap.xss.hr.wiw.FcWiwBusinessLogicComp.onInit(FcWiwBusinessLogicComp.java:217) at com.sap.xss.hr.wiw.wdp.InternalFcWiwBusinessLogicComp.onInit(InternalFcWiwBusinessLogicComp.java:414) at com.sap.xss.hr.wiw.FcWiwBusinessLogicCompInterface.onInit(FcWiwBusinessLogicCompInterface.java:115) at com.sap.xss.hr.wiw.wdp.InternalFcWiwBusinessLogicCompInterface.onInit(InternalFcWiwBusinessLogicCompInterface.java:298) at com.sap.xss.hr.wiw.wdp.InternalFcWiwBusinessLogicCompInterface$External.onInit(InternalFcWiwBusinessLogicCompInterface.java:358) at com.sap.pcuigp.xssfpm.wd.FPMComponent$FPM.attachComponentToUsage(FPMComponent.java:922) at com.sap.pcuigp.xssfpm.wd.FPMComponent$FPM.attachComponentToUsage(FPMComponent.java:891) at com.sap.pcuigp.xssfpm.wd.FPMComponent$FPMProxy.attachComponentToUsage(FPMComponent.java:1084) at com.sap.xss.hr.wiw.selection.VcWiwSelectionComp.onInit(VcWiwSelectionComp.java:212) at com.sap.xss.hr.wiw.selection.wdp.InternalVcWiwSelectionComp.onInit(InternalVcWiwSelectionComp.java:206) at com.sap.xss.hr.wiw.selection.VcWiwSelectionCompInterface.onInit(VcWiwSelectionCompInterface.java:162) at com.sap.xss.hr.wiw.selection.wdp.InternalVcWiwSelectionCompInterface.onInit(InternalVcWiwSelectionCompInterface.java:144) at com.sap.xss.hr.wiw.selection.wdp.InternalVcWiwSelectionCompInterface$External.onInit(InternalVcWiwSelectionCompInterface.java:220) at com.sap.pcuigp.xssfpm.wd.FPMComponent.doProcessEvent(FPMComponent.java:564) at com.sap.pcuigp.xssfpm.wd.FPMComponent.doEventLoop(FPMComponent.java:438) at com.sap.pcuigp.xssfpm.wd.FPMComponent.wdDoInit(FPMComponent.java:196) at com.sap.pcuigp.xssfpm.wd.wdp.InternalFPMComponent.wdDoInit(InternalFPMComponent.java:110) at com.sap.tc.webdynpro.progmodel.generation.DelegatingComponent.doInit(DelegatingComponent.java:108) at com.sap.tc.webdynpro.progmodel.controller.Controller.initController(Controller.java:215) at com.sap.tc.webdynpro.progmodel.controller.Controller.init(Controller.java:200) 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:754) at com.sap.tc.webdynpro.clientserver.session.ApplicationSession.doProcessing(ApplicationSession.java:289) at com.sap.tc.webdynpro.clientserver.session.ClientSession.doApplicationProcessingPortal(ClientSession.java:733) at com.sap.tc.webdynpro.clientserver.session.ClientSession.doApplicationProcessing(ClientSession.java:668) at com.sap.tc.webdynpro.clientserver.session.ClientSession.doProcessing(ClientSession.java:250) at com.sap.tc.webdynpro.clientserver.session.RequestManager.doProcessing(RequestManager.java:149) at com.sap.tc.webdynpro.clientserver.session.core.ApplicationHandle.doProcessing(ApplicationHandle.java:73) at com.sap.tc.webdynpro.portal.pb.impl.AbstractApplicationProxy.sendDataAndProcessActionInternal(AbstractApplicationProxy.java:860) at com.sap.tc.webdynpro.portal.pb.impl.AbstractApplicationProxy.create(AbstractApplicationProxy.java:220) at com.sap.portal.pb.PageBuilder.updateApplications(PageBuilder.java:1289) at com.sap.portal.pb.PageBuilder.createPage(PageBuilder.java:356) at com.sap.portal.pb.PageBuilder.init(PageBuilder.java:549) at com.sap.portal.pb.PageBuilder.wdDoRefresh(PageBuilder.java:593) at com.sap.portal.pb.PageBuilder$1.doPhase(PageBuilder.java:865) at com.sap.tc.webdynpro.clientserver.window.WindowPhaseModel.processPhaseListener(WindowPhaseModel.java:755) at com.sap.tc.webdynpro.clientserver.window.WindowPhaseModel.doPortalDispatch(WindowPhaseModel.java:717) at com.sap.tc.webdynpro.clientserver.window.WindowPhaseModel.processRequest(WindowPhaseModel.java:136) at com.sap.tc.webdynpro.clientserver.window.WebDynproWindow.processRequest(WebDynproWindow.java:335) at com.sap.tc.webdynpro.clientserver.cal.AbstractClient.executeTasks(AbstractClient.java:143) at com.sap.tc.webdynpro.clientserver.session.ApplicationSession.doProcessing(ApplicationSession.java:319) at com.sap.tc.webdynpro.clientserver.session.ClientSession.doApplicationProcessing(ClientSession.java:684) at com.sap.tc.webdynpro.clientserver.session.ClientSession.doProcessing(ClientSession.java:250) 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.doPost(DispatcherServlet.java:53) at javax.servlet.http.HttpServlet.service(HttpServlet.java:760) 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:1039) 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(AccessController.java:219) at com.sap.engine.core.thread.impl3.SingleThread.execute(SingleThread.java:104) at com.sap.engine.core.thread.impl3.SingleThread.run(SingleThread.java:176)

Sap-wd-arfc-useSys

Hi ,
I have tired to change the RFC destinations of the model that was created in design time , using the url parameter
sap-wd-arfc-useSys as specifed in :
http://help.sap.com/saphelp_nw04/helpdata/en/f4/651741f163f023e10000000a155106/content.htm
but it does not work , and I don't know why ,
Just to mention the RFC metadata and nodel data in design time are not the default ones .
It says on the link that the webdynpro application should not be running when configuring those destinations

Hi,
Right click ur project >properties>webdynpro References>JCo references-chage the metadata and modeldata.......rebild ur project and then deploy it...
I hope it will solve ur problem...
Regards,
Yash

Invalidate ARFC Metadata Cache

Hi,
I am working on NW 7.0 S 12.
Everytime I make changes to my Adaptive RFC I require to take a J2EE server restart to invalidate the metadata cache. I am aware of the 'Invalidation of ARFC Metadata Cache link under Web Dynpro Console on the Porta
I am unable to find this link under Web Dynpro Console -> Admin Menu.
I found the document [Metadata Cache Invalidation for Adaptive RFC Models|http://www.sdn.sap.com/irj/scn/index?rid=/library/uuid/10465350-b4f5-2910-61ba-a58282b3b6df]
on SDN by Arun Bhat J which says I can download EARs from SDN for NW7.0 and deploy as a Web Dynpro application.
I have tried this activity by importing the file structure in NWDS as a Web Dynpro Application/ J2EE Application/ Java Application. None of these helped me deploy file structure.
I would like to make this link of 'Invalidation of Cache' available on the portal. How can I achieve this. Also, I have downloaded the files mentioned in the document. How can I use this to solve my problem.
Thanks in advance.

Leo van Hengel wrote:
> However my real advice would be to patch your portal. SP12 (2007) is really old
>
> Cheers,
> Leo
We have the same problem in CE7.2.
Everytime when we change structure in ABAP or in WS - we have to restart CE
cliaring JCO Cache in nwa "JCO monitoring" helps 50/50...
Edited by: Pavel Korgenevskiy on Feb 3, 2012 6:01 AM

JCO details thru Application parameters

Hi Experts,
I have a scenario where one web dnypro application has to access data from multiple R3 systems using different JCOs.
For example:
System Client
ABV 120
ABV 210
ABX 120
I have JCOs created for each systems :
ABV 120:
JCO : WD_ECC_MODELDATA_DESTABV
 WD_ECC_METADATA_DESTABV
ABV 210:
JCO : WD_ECC_MODELDATA_DESTABV210
 WD_ECC_METADATA_DESTABV210
ABX 120:
JCO : WD_ECC_MODELDATA_DESTABX120
 WD_ECC_METADATA_DESTABX120
In the webdynpro Iview I am using the property Application Parameters where Iam setting the JCOs which it has to access for.
Like shown below:
For ABV 120:
sap.wdarfc.useSys=WD_ECC_MODELDATA_DEST:ABV&sap.wdarfc.useSys=WD_ECC_METADATA_DEST:ABV
For ABV 210:
sap.wdarfc.useSys=WD_ECC_MODELDATA_DESTABV210:ABV&sap.wdarfc.useSys=WD_ECC_METADATA_DESTABV210:ABV
For ABX 210:
sap.wdarfc.useSys=WD_ECC_MODELDATA_DESTABX210:ABX&sap.wdarfc.useSys=WD_ECC_METADATA_DESTABX210:ABX
But i see this way it is not working and every Application is using the Default JCos (WD_ECC_MODELDATA_DEST and WD_ECC_METADATA_DEST) which are pointed to ABV210.
Can anyone pls suggest as we are going critical now.
Regards,
Kumar

The new system name used in the URL must begin with the previous system name and be at most 3 characters longer than the previous name.
So, you cannot have ABV210 as the suffix. The suffix should be at most 3 chars.
Please use it as follows:
sap-wd-arfc-useSys=SAP_R3_HumanResources:QAS&sap-wd-arfc-useSys=SAP_R3_HumanResources_Metadata:QAS
It should be <Default System>:<Suffix of Mapped System>
Your default system is - SAP_R3_HumanResources
Mapped system is - SAP_R3_HumanResourcesQAS
So suffix of the mapped system is - QAS
Hope that explains it.
Check this doc (page 17) for more info:
http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/526bd490-0201-0010-038e-d3ff7eb1d16e?quicklink=index&overridelayout=true
- Shanti

JCO vs aRFC

Similar Messages

Maybe you are looking for