metadata cache invalidation for adaptive rfc models

Metadata Cache Invalidation for Adaptive RFC Models

SAP DEVELOPER NETWORK | sdn.sap.com BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com © 2007 SAP AG 1


Applies to: Adaptive RFC model is available with Web Dynpro for Java. The article provides the metadata cache invalidation solution for NW 6.40, 7.0 and 7.1 releases.

Summary The Adaptive RFC Model provides a Web Dynpro model implementation for backend R/3 System. Customers have regularly complained that the model is not adaptive enough to changes on the R/3 System unless the J2EE Engine is restarted. This article makes an attempt to solve this problem. Author: Arun Bhat J Company: SAP Labs India Private Ltd. Created on: 30 April 2007

Author Bio Arun Bhat works as a Development Lead at SAP Labs in the Web Dynpro UI Development area. He earlier worked in the Mobile Web Dynpro Offline Client area for two years since he joined SAP in Feb 2004. Currently he has been working on Web Dynpro models, Context and other related areas of the Web Dynpro framework.



Table of Contents Applies to: ........................................................................................................................................ 1 Summary.......................................................................................................................................... 1 Author Bio ........................................................................................................................................ 1 1. Current Problems with the Adaptive RFC Model.................................................................. 2 2. Reasoning why the metadata is not refreshed ..................................................................... 5 3. Scenarios for Cache Invalidation .......................................................................................... 5 4. Accessing the ARFC Metadata Cache Invalidation Tool.................................................... 10 5. Disclaimer ........................................................................................................................... 12 6. Related Content .................................................................................................................. 12 7. Acknowledgements............................................................................................................. 13 Copyright........................................................................................................................................ 14

1. Current Problems with the Adaptive RFC Model The Adaptive RFC Model currently available with NW 6.40, 7.0 and 7.1 Releases may not always adapt to changes in the metadata, that is data types/metadata of the R/3 system from which the model pulls data. Maybe 2 simple scenarios should explain in greater detail the problem.

1. The tool tips on the Adaptive RFC are pulled from the R/3 Backend. Something like below. See “Value of Attribute“ which is a tool top that shows up for the “TestAttr” input field.

Fig1. Tool Tips read from the backend through the Data Dictionary If this were changed on the R/3 as shown in the Short Description as “Value of Test Attribute CHANGED !” (Fig2. Changing the description on the R/3) then this should also be visible in the Fig1.shown above, but it does not. The output continues to be the same.



Fig2.Changing Data Element Descriptions on the R/3 Backend

2. Let’s say there are some changes on the BAPI side itself. For example that the import/export parameters of the BAPI get changed.

For example the “TEST_ATTR” of the import parameter of the below BAPI Changed .Then the current solution doesn’t really work.



Fig3.Renaming of the attribute of a BAPI When the application is launched and run it rather doesn’t find the new “TEST_ATTR1” type and the program crashes like with the error below.

Fig3 Error after running a re-imported model currently without server restart



2. Reasoning why the metadata is not refreshed The Web Dynpro Adaptive RFC framework sits on the top of several layers such as the Java Connector Objects (JCO), Data Dictionary (DDIC) and the MDI. After the first access each of these layers caches the metadata within them and keeps returning the cached values thereafter. The caches are not refreshed even if something would have changed in the metadata on the R/3 backend. In addition the Web Dynpro ARFC model itself also caches the metadata. The new invalidation tool will try to refreshes the caches across all the layers. The earlier solution to refresh the caches was to simply restart the engine.

3. Scenarios for Cache Invalidation Customers have two scenarios across which they can use the Adaptive RFC Metadata Cache invalidation tool. They are

1. Development Scenarios – These scenarios involve not adapting the metadata to a running productive system. They are scenarios with respect to development where the Adaptive RFC model will have to be re-imported on the IDE and the application re-deployed on the engine. The redeployment is important because it also clears the Web Dynpro’s Adaptive RFC Cache.

The scenarios are usually those that you would refresh the JCO Caches. The examples being

a. Addition of import/export parameters/table parameters to the BAPI

b. Deletion of import/export parameters/table parameters of the BAPI

c. Renaming of existing parameters of a BAPI.

d. Change of associated type of a parameter in the BAPI.

All of these scenarios would need a “MODEL RE-IMPORT” on the IDE. The binding in the application will then need to be re-configured and adjusted with the new attributes in the model classes. The application then needs to be built and re-deployed. Before redeploying the application the ARFC Meta data Cache Invalidation application needs to be launched and run. Once there follow the following steps.

a. The screen shows up something like this.



Fig4. The ARFC Application as launched through the Web Dynpro Console.

b. Once here click on the “Get JCO Destinations” .This will list all the JCO Destinations. There is a check box in the second column which indicates “Don’t Cache”. This means for that JCO destination which uses the BAPI, checking the box will not cache any metadata and always get it from the backend. Remember this doesn’t cache any metadata and always gets all metadata from the backend. This should be used only for the first access of the BAPI after the metadata on the R/3 has been changed (that is running of the actual application). After the “Don’t Cache” has been checked and the actual application is run we now access the changed ARFC metadata. After this you can uncheck the “Don’t Cache”, so that the Caching becomes active. This will help in improved Performance. For Production Scenarios NEVER CHECK THE “Don’t Cache!”

Please remember you always only check the Metadata JCO Destination only.



Fig 5.Non caching of the JCO Metadata Destinations

c. Next step is also to invalidate the related Data Dictionary Caches. Choose the metadata JCO Destination in question and click on “Get Dictionaries for Selected JCO Destination” .This will list all the Data Dictionaries of that JCO Destination. Check the invalidate Cache for all dictionaries and click on the “Invalidate Selected Dictionary Cache” button. This will clear the Data Dictionary Cache. This just invalidates the cache and doesn’t necessarily get the metadata every time from the backend. So this is not similar to Point b above.

There are 2 different ways of using the Dictionary invalidation. These will be discussed in the next topic.



Fig6. DDIC Cache Invalidation after model re-import

2. Production Scenarios – The production scenarios are those where any productive ARFC Web Dynpro system running in a customer environment can adapt to the metadata changes just by a browser refresh. There will be no need to “Restart the J2EE Engine “. Example Scenarios are those that involve refreshing the Data Dictionary Cache. Some of these are

1. “Short Description” change of Data Elements. 2. Changes in Value Range of Domains on the backend etc. 3. Mostly things that have anything to do with Dictionary. After running through the invalidation tool (as in Fig 6) the browser in which the application runs can simply be refreshed to get the updated dictionary metadata. Please note that it’s not necessary to click on the “Don’t Cache” in the upper JCO Destination table if you need to use the Dictionary Invalidation. The above way allows you to select JCO Dictionaries for that destination and invalidate it. Since this runs through a lot of computing, getting the list of dictionaries may not always be best in performance. For performance there is an alternate option where the Dictionary can be invalidated just by typing the name of the dictionary.



Fig7. Manually entering Data Dictionary for invalidation The text box expects the name of the dictionary along with the package name. The package name is the name of the model appending with “.types”. So if there is a ARFC model “com.sap.test.Test”, then the dictionary package is “com.sap.test.types.Test”. Examples for the data Dictionary invalidation are like the above where after Short Description of the data element has been changed, the dictionary invalidation is done and refreshing the browser page will reflect the new changed values.

. Secondly when an enumeration is changed in the backend for a application, this can immediately reflect after Data Dictionary Cache Invalidation.

Fig8. A enumeration in a Web Dynpro application retrieved through a domain Let’s now add a new “Val4” to the Domain on the R/3.



Fig9. The value range is extended for a domain on the R/3 backend After Dictionary Cache invalidation and browser refresh, this immediately reflects in the application.

Fig10. Updated enumeration values reflecting on the UI

4. Accessing the ARFC Metadata Cache Invalidation Tool The Metadata Cache Invalidation Tool would be made available from the following releases

1. NW04 or 6.40 SP21 Onwards

2. NW04S or 7.0 SP12 Onwards



3. NW 7.1 SP3 Onwards.

This can be accessed through the Web Console application.

Fig11. Link to the Web Dynpro console Once there in the left pane click on the “Invalidation of ARFC Metadata Cache” to launch the application.



For older releases please download the following ears from the SDN. Deploy them as normal Web Dynpro applications and run them through the Content Administrator. Here too this supported only from the following releases

1. NW04 or 6.40 SP20 Onwards

2. NW04s or 7.0 SPS10 Onwards.

The ear files can be found here: NW 6.40NW 7.0 NW 7.1

5. Disclaimer The tool has been intended for ease of use and may not have tested all scenarios. In case some features don’t update, please restart the J2EE engine. Any support needed will be provided for the versions mentioned above released with the Web Dynpro Console.

6. Related Content Please include at least three references to SDN documents or web pages.

1. Adaptive RFC Trouble Shooting Guide

2. How to use the Web Dynpro Content Administrator

3. Adaptive RFC Documentation

4. JCO Quick Summary

http://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/90e486ef-a9f5-2910-23a3-d518323d7a5e

http://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/503c5a4a-aaf5-2910-cb91-c91f360b3a29

http://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/40e5a169-aaf5-2910-04ae-d9e3c03600ac

https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/f3f93ee7-0c01-0010-2593-d7c28b5377c2

https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/f3f93ee7-0c01-0010-2593-d7c28b5377c2

http://help.sap.com/saphelp_nw04/helpdata/en/41/38bc8f813719488ddc9d9b21251ec3/frameset.htm

https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/85a483cb-0d01-0010-2990-c5168f01ce8a



7. Acknowledgements

Thanks to Patric Ksinsik for his help in guiding through this topic



Copyright © Copyright 2007 SAP AG. All rights reserved.

No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice.

Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors.

Microsoft, Windows, Outlook, and PowerPoint are registered trademarks of Microsoft Corporation.

IBM, DB2, DB2 Universal Database, OS/2, Parallel Sysplex, MVS/ESA, AIX, S/390, AS/400, OS/390, OS/400, iSeries, pSeries, xSeries, zSeries, z/OS, AFP, Intelligent Miner, WebSphere, Netfinity, Tivoli, Informix, i5/OS, POWER, POWER5, OpenPower and PowerPC are trademarks or registered trademarks of IBM Corporation.

Adobe, the Adobe logo, Acrobat, PostScript, and Reader are either trademarks or registered trademarks of Adobe Systems Incorporated in the United States and/or other countries.

Oracle is a registered trademark of Oracle Corporation.

UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group.

Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are trademarks or registered trademarks of Citrix Systems, Inc.

HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C®, World Wide Web Consortium, Massachusetts Institute of Technology.

Java is a registered trademark of Sun Microsystems, Inc.

JavaScript is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by Netscape.

MaxDB is a trademark of MySQL AB, Sweden.

SAP, R/3, mySAP, mySAP.com, xApps, xApp, SAP NetWeaver, and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other product and service names mentioned are the trademarks of their respective companies. Data contained in this document serves informational purposes only. National product specifications may vary.

These materials are subject to change without notice. These materials are provided by SAP AG and its affiliated companies ("SAP Group") for informational purposes only, without representation or warranty of any kind, and SAP Group shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty.

These materials are provided “as is” without a warranty of any kind, either express or implied, including but not limited to, the implied warranties of merchantability, fitness for a particular purpose, or non-infringement.

SAP shall not be liable for damages of any kind including without limitation direct, special, indirect, or consequential damages that may result from the use of these materials.

SAP does not warrant the accuracy or completeness of the information, text, graphics, links or other items contained within these materials. SAP has no control over the information that you may access through the use of hot links contained in these materials and does not endorse your use of third party web pages nor provide any warranty whatsoever relating to third party web pages.

Any software coding and/or code lines/strings (“Code”) included in this documentation are only examples and are not intended to be used in a productive system environment. The Code is only intended better explain and visualize the syntax and phrasing rules of certain coding. SAP does not warrant the correctness and completeness of the Code given herein, and SAP shall not be liable for errors or damages caused by the usage of the Code, except if such damages were caused by SAP intentionally or grossly negligent.

metadata cache invalidation for adaptive rfc models

Documents