Best Practice for Downgrading J2EE/Portal Patch Version

Hello all,
We're trying to determine the best path to follow and would appreciate any advice. We have an existing Portal implementation with ESS/MSS which has been live for almost a year. It is on NW2004s (i.e., 7.0) and in production it is on ERP stack 8 (ESS stack 8, J2EE stack 11), which matches up with the backend ECC system for the most part. The Portal is under NWDI control, as we have customized the ESS and MSS web dynpros a little bit. So far so good.
However, we were starting a round of implementing SP stacks this summer, and after getting started with the DEV portal, getting it up to ESS stack 12, J2EE stack 14, the organization decided, due to workload and time constraints, to defer the SP stack application for six months. So, the new sp stack is only in the DEV portal, it's not in QA or PRD, and it's not on the DEV ECC system. We have learned, and experienced for ourselves, that there are certain functions which do not work, or do not work well, in MSS when the MSS Portal components are at a higher sp level than the ECC HR components, and we don't really want to have the DEV Portal out of sync with its backend, as well as QA and PRD, for six months. This is especially true as when we revisit the sp's in six months, it will no doubt be to a higher stack level, and this out-of-sync condition will just complicate things then.
So, we'd like to roll the DEV portal back to its prior sp level. The question is, how? There doesn't appear to be a way to do it with JSPM. Should we use SDM with the "update deployed SDAs/SCAs that have any version" option to overwrite the newer components with the older one? Or should we use SDM to undeploy what's on there now and just redeploy the older components with JSPM? With either of these options, what complications will we encounter with NWDI? Or should we try to restore the DEV portal from backup?
And if we do restore from backup... well, just what's involved in that? I'm fully conversant with restoring ABAP systems (we are on SQL Server 2005 by the way), even migrating ABAP systems to new servers, changing SIDs, refreshing QA systems from PRD, all of that. But I haven't worked as long with the J2EE engine, and I'm aware that much of the 'system' is not actually in the database, but in the filesystem. So, which folders would I need to restore along with the database? What considerations with NWDI do I need to be cognizant of? I haven't found any guides or recommendations on this approach so far, so I'm hoping for some direction here.
Best regards, and thanks in advance,
Matt

Hello Matt,
First let me correct you on the statement that most part of the J2EE is on the file system. That is no true. Most part of J2EE Engine is kept in the DB and on the file system. Everything under /j2ee/cluster/dispatcher and /j2ee/cluster/serverX is in the database and if you delete these folders they will be fully restored on startup of the server.
You can not undeploy the core components of the J2EE Engine and then redeploy them. If you do that significant part of the information generated during the installation will be lost and the J2EE Engine will be almost irreversibly broken.
Forced redeployment of the older version works for single applications, but on a grand scale I donu2019t think it will work. There are too many dependencies that will be broken and the deployments of many components will fail.
That leaves us with two options.
1. Restore from backup. Please refer to the following link for information:
http://help.sap.com/saphelp_nw04/helpdata/en/4b/d8f23ea4b42e5ae10000000a114084/frameset.htm
2. System copy from some of the other systems.
There are different kinds of system copy. Please start from the following link for basic information about system copy:
http://help.sap.com/saphelp_nw70/helpdata/en/a2/2f0c173a5e43d19585724239ff4de7/frameset.htm
For more comprehensive information see SAP Service Marketplace at http://service.sap.com/systemcopy
Regards,
Ventsi Tsachev
Technology Development Support (J2EE Engine)
SAP Labs, Palo Alto, Ca (USA)

Similar Messages

Best practice for management of Portal personalisation

Hi
I've been working in our sandpit client figuring out all portal personalisation and backend/frontend customisation for ESS (with some great help from SDN). However I'm not clear on what best practice is when doing this for 'real'.
I've read in places that objects to be personalised should be copied first. Elsewhere I've read about the creating of a new portal desktop for changes to the default framework page etc
What I'm not clear on is the strategy for how you manage and control all the personalisation changes. For example, if you copy an iview and personalise where do you copy it to? Do you create "Z" versions of all the folders of the standard content or something else?
Do you copy everything at the lowest possible object level and copy or highest?
Implications of applying support or enhancement packs?
We're going pretty vanilla to begin with in that there will just be a single ESS role so things should be fairly simple from that point of view, but I've trawled all around SDN without being able to find clear guidance on the overall best pratice process for personalisation.
Can anyone help?
Regards
Phil
Edited by: Phil Martin on Feb 15, 2010 6:47 PM

Hi Phil,
To keep things organized I would create an new folder (so don't use the desktop one). The new folder should sit under Portal Content. In that folder create a folder for ESS, then inside that one for iViews (e.g. COMPANY_XYZ >>> ESS >>> iViews) then copy via delta link the iViews you want from the standard SAP folders.
Then you will have to create another folder for your own roles (e.g. ESS >>> Roles). Inside this folder create a new role and add your iViews (again via delta link). Or you could just copy one of the standard SAP roles into this folder and not bother with copying the iViews. What you do depends on how many changes you intend to make, sometimes if the changes are only small it is easier to copy the entire SAP role (via delta link) and make your changes.
You should end up with something link this in your PCD:
Portal Content
     COMPANY_XYZ
          ESS
               iViews
                    iView1
                    iView2 etc..
               Roles
                    Role1
                    Role2 etc...
Then don't forget to assign your new roles to your users or groups.
Hope that makes sense.
BRgds,
Simon
Edited by: Simon Kemp on Feb 16, 2010 3:56 PM

Best practice for migrating between environments and versions?

Hi to all,
we've got a full suite of solutions custom developed in SAP BPC 7.0, SP 7. We'd like to understand if
- there are best practice in order to copy this applications from an environment to another environment (another client)
- there are best practice in case the client has got a newer version of SAP BPC (they should install the 7.5, while we're still stucked with the 7.0).
Thank you very much
Daniele

Hi Daniele
I am not entirely sure, what you are asking, Please could you provide additional information.
Are you looking for best practice recommendations for Governance, for example: Change transports between DEV, QA and PRD in BPC 7.0?
What is the best method? Server Manager backup and restore, etc ?
And
Best Practice recommendations on how to upgrade to a different version of BPC, for example: Upgrading from BPC 7.0 to 7.5 or 10.0 ?
Kind Regards
Daniel

Best Practice for Portal Patches and effort estimation

Hi ,
One of our client is applying the following patches
1. ECC 6.0 SP15(currently SP14)
2. ESS MSS SP15(currently SP14 with some level of functional customization )
3. EP 7 SP18(currently SP14)
We would like to kwow the best practice for applying portal patches and the effort estimation for redoing the portal devt on the new patch.
o   What is the overall level of effort with applying Portal patches?
o   How are all the changes to SAP objects handle? Do they have to be
     manually re-entered?
o What is the impact of having a single NWDI instance across the
    Portal Landscape during the Patch process?
Regards,
Revathi Raju.

Hi Revathi,
o What is the overall level of effort with applying Portal patches?
overall effort to apply the patch is apprx 1/2-1 days for NW7 system. This is exclude the patch files download because it's based on your download speed.
o How are all the changes to SAP objects handle? Do they have to be
manually re-entered?
Depending on your customization. Normally it wont effect if you created the customzation application apart from SAP standard application
o What is the impact of having a single NWDI instance across the
Portal Landscape during the Patch process?
Any change that related to NWDI, you might be need to re-deployed from NWDI itself.
Thanks
Regards,
AZLY

Best practice for distributing/releasing J2EE applications.

Hi All,
We are developing a J2EE application and would like some information on the best
practices to be followed for distributing/releasing J2EE applications, in general.
In particular, the dilemma we have is centered around the generation of stub, skeleton
and additional classes for the application.
Most App. Servers can generate the required classes while deploying the EJBs in the
application i.e. at install time. While some ( BEA Weblogic and IBM Websphere are
two that we are aware of ) allow these classes to be generated before the installation
time and the .ear file containing the additional classes is the one that is uploaded.
For instance, say we have assembled the application "myapp.ear" . There are two ways
in which the classes can be generated. The first is using 'ejbc' ( assume we are
using BEA Weblogic ), which generates the stub, skeleton and additional classes for
the application and returns the file, say, "Deployable_myapp.ear" containing all
the necessary classes and files. This file is the one that is then installed. The
other option is to install the file "myapp.ear" and let the Weblogic App. server
itself, generate the required classes at the installation time.
If the first way, of 'pre-generating' the stubs is followed, does it require us to
separately generate the stubs for each versions of the App. Server that we support
? i.e. if we generate a deployable file having the required classes using the 'ejbc'
of Weblogic Ver5.1, can the same file be installed on Weblogic Ver6.1 or do we
have to generate a separate file?
If the second method, of 'install-time-generation' of stubs is used, what is the
nature/magnitude of the risk that we are taking in terms of the failure of the installation
Any links to useful resources as well as comments/suggestions will be appreciated.
TIA
Regards,
Aasif

Its much easier to distribute schema/data from an older version to a newer one than the other way around. Nearly all SQL Server deployment features supports database version upgrade, and these include the "Copy Database" wizard, BACKUP/RESTORE,
detach/attach, script generation, Microsoft Sync framework, and a few others.
EVEN if you just want to distribute schemas, you may want to distribute the entire database, and then truncate the tables to purge data.
Backing up and restoring your database is by far the most RELIABLE method of distributing it, but it may not be pratical in some cases because you'll need to generate a new backup every time a schema change occurs, but not if you already have an automated
backup/maintenance routine in your environment.
As an alternative, you can Copy Database functionality in SSMS, although it may present itself unstable in some situations, specially if you are distributing across multiple subnets and/or domains. It will also require you to purge data if/when applicable.
Another option is to detach your database, copy its files, and then attach them in both the source and destination instances. It will generate downtime for your detached databases, so there are better methods for distribution available.
And then there is the previously mentioned method of generating scripts for schema, and then using an INSERT statement or the import data wizard available in SSMS (which is very practical and implements a SSIS package internally that can be saved for repeated
executions). Works fine, not as practical as the other options, but is the best way for distributing databases when their version is being downgraded.
With all this said, there is no "best practice" for this. There are multiple features, each offering their own advantages and downfalls which allow them to align to different business requirements.

What are best practice for packaging and deploying j2EE apps to iAS?

We've been running a set of J2EE applications on a pair of iAS SP1b for about a year and it has been quite stable.
Recently however we have had a number of LDAP issues, particularly when registering and unregistering applications (registering ear files sometimes fails 1st time but may work 2nd time). Also We've noticed very occasionally that old versions of classes sometimes find their way onto our machines.
What is considered to be best practice in terms of packaging and deployment, specifically:
1) Packaging - using the deployTool that comes with iAS6 SP1b to package is a big manual task, especially when you have 200+ jsp files. Are people out there using this or are they scripting it with a build tool such as Ant?
2) Deploying an existing application to multiple iAS's. Are you guys unregistering old application then reregistering new application? Are you shutting down iAS whilst doing the deployment?
3) Deploying ear files can take 5 to 10 mins, is this normal?
4) In a clustered scenario where HTTPSession is shared what are the consequences of doing deployments to data stored in session?
thanks in asvance for your replies
Owen

You may want to consider upgrading your application server environment to a newer service pack. There are numerous enhancements involving the deployment tool and run time layout of your application that make clear where you're application is loading its files from.
If you've at a long running application server environment, with lots of deployments under your belt, you might start to notice slow downs in deployment and kjs start time. Generally this is due to garbage collecting in your iAS registry.
You can do several things to resolve this. The most complete solution is to reinstall the application server. This will guarantee a clean ldap registry. Of course you've got to restablish your configurations and redeploy your applications. When done, backup your application server install space with the application server and directory server off. You can use this backup to return to a known configuation at some future time.
For the second method: <B>BE CAREFUL - BACKUP FIRST</B>
There is a more exhaustive solution that involves examining your deployed components to determine the active GUIDS. You then search the NameTrans section of the registry searching for Applogic Servlet *, and Bean * entries that represent your previously deployed components but are represented in the set of deployed GUIDs. Record these older GUIDs, remove them from ClassImp and ClassDef. Finally remove the older entries from NameTrans.
Best practices for deployment depend on your particular environmental needs. Many people utilize ANT as a build tool. In later versions of the application server, complete ANT scripts are included that address compiling, assembly and deployment. Ant 1.4 includes iAS specific targets and general J2EE targets. There are iAS specific targets that can be utilized with the 1.3 version. Specialized build targets are not required however to deploy to iAS.
Newer versions of the deployment tool allow you to specify that JSPs are not to be registered automatically. This can be significant if deployment times lag. Registered JSP's however benefit more fully from the services that iAS offers.
2) In general it is better to undeploy then redeploy. However, if you know that you're not changing GUIDs, recreating an existing application with new GUIDs, or removing registered components, you may avoid the undeploy phase.
If you shut down the KJS processes during deployment you can eliminate some addition workload on the LDAP server which really gets pounded during deployment. This is because the KJS processes detect changes and do registry loads to repopulate their caches. This can happen many times during a deployment and does not provide any benefit.
3) Deploying can be a lengthy process. There have been improvements in that performance from service pack to service pack but unfortunately you wont see dramatic drops in deployment times.
One thing you can do to reduce deployment times is to understand the type of deployment. If you have not manipulated your deployment descriptors in any way, then there is no need to deploy. Simply drop your newer bits in to the run time space of the application server. In later service packs this means exploding the package (ear,war, or jar) in to the appropriate subdirectory of the APPS directory.
4) If you've changed the classes of objects that have been placed in HTTPSession, you may find that you can no longer utilize those objects. For that reason, it is suggested that objects placed in session be kept as simple as possible in order to minimize this effect. In general however, is not a good idea to change a web application during the life span of a session.

Business Package for SAP Best Practices for Enterprise Portal

Hi,
We are implementing EP for ECC 5.0 and we have to web enable some FI transactions like FB50/fb60 etc. We want to use standard business package for this. The only business package that caters this requirement is "Business Package for SAP Best Practices for Enterprise Portal 60.1". When i checked the data source for this business package, the specification is for "SAP R/3 4.6B and above". Does this work for ECC 5.0 as well? In general does the R/3 specific business packages work for ECC versions? Please let me know. Thanks for the help. I promise rewards.
Regards
Hari

Hari,
When you download the BPO via Portal Content Portfolio,
each bpo has additional information on the release.
For example for the one you are inquiring about - Business Package for SAP Best Practices for Enterprise Portal, the additional release information is provided on the following links;
https://www2.iviewstudio.com/sdn/info/index.cfm?action=faqs&part=#QSR03
https://www2.iviewstudio.com/sdn/detail_view/index.cfm?action=package_information&CatalogSet=SAP%20Content&ItemID=17212&CFID=7544845&CFTOKEN=99283970
Regards,
James

Best Practices for standardizing long text for EP GUI version

Hello, I have a question that is related to standardizing best practices for all portal applications that use EP
1) The portal team has recommended activating the GUI version from portal to allow the long text to have the same features as the standard GUI. Since this solution is per transaction, we will need to identify what transactions need to have this temporary solution built in. Also, business users will need to remember which transactions they will access via portal or GUI.
(2) Even though the long text function is activated via GUI per transaction, the system will prompt a message of u201CRuntime Error! Program C:\Program Files\Microsoft Office\OFFICE11\WINWORD.EXEu201D. This may create frustrations to the users each time they maintain the long text. The risk of this may be losing the use of long text throughout the maintenance orders, production orders, notifications, material masters, equipment masters, maintenance task lists, production routings, etc.
All feedback welcomed
Thanks Mark

I found the solution, make everything in Illustrator (well text anyway) at a big size then bring it ibto Photoshop in a dicument 1024 x 576 (so no widescreen pixel ratio) then when saving document bring size of Image to 720 x 576 then you get great anti aliased pictures.
Solved.

Best practice for version control B2B, ESB and BPEL

Hello,
we are setting up a new system using B2B, ESB and BPEL. The development team is more experienced working with PL/SQL, Oracle Workflow and we are worried that Jdeveloper generates changes to the source files during development and that we might have problems with the version control.
Is there any best practice for setting up version control for these systems? Do we need to take anything in particular into consideration when setting up the projects?
We are using Serena Dimensions 9.1 for version control with the add-on in Jdeveloper.
Thanks in advance!

I believe JDeveloper has a plugin for Dimensions.
I havent used it but to get it, go to tools (It may be help I don't have JDeveloper on this machine to confirm) check for updates.
If you select the thrid party check box - next, you will see an entry for dimentions.
Configure the connection and develop as you would any other project.
cheers
James

EFP and Intranet Portal - Best Practices for architecture

Hi All,
   We are planning to create a portal for our partners (b2b scenario). This portal will provide anonymous and user specific access. We also have a intranet portal with ESS and MSS. I have some doubts around implementing EFP and Intranet portal.
   1) What is the best practice solution architecture around portal instances? Is it suggested to implement both intranet and internal portals on same portal instance? Do you implement them as 2 seperate instances (and 2 seperate boxes) one for intranet and another for internet?
   2) There are couple of functions shared between inranet and internet portals. Has any one attempted   a FPN connection between a internet portal and intranet portal?
   3) What is the best practices around an external portal connecting to ECC directly?
Any suggestions are greatly appreciated.

Hi Pallayya,
         We are implementing a similar kind of thing for our client.I can explain that so you find some glimpse out of it.
We have decided twp ways.
1) We are having one instance of the portal that will be accessed both in Intranet & Internet.We are using two different URL for intranet & internet.We have a reverse proxy in the picture also,coz it will increase the security of the portal in the Internet.The reverse proxy will be available in the DMZ Zone.We have integrated ECC & BW with the portal and some web dynpro application(For intranet only).
Now the user comes from the Internet will hit the reverse proxy first->then it will go to EP Server->in EP it will be decided which kind of request client is asking ->
If it is a ECC request->Portal Server sends back the request to Reverse Proxy->RP will send it to web dispatcher->Then it will go to ECC.
If it is a BW request ->Portal server sends the request to BW Server.
2) There will be two different URLS for the portal in Intranet & Internet
     For that we used two reverse proxy
regards
Indranil

Best Practices For Portal Content Objects Transport System

Hi All,
I am going to make some documentation on Transport Sytem for Portal content objects in Best Practices.
Please help in out and send me some documents related to SAP Best Practices for transport for Portal Content Objects.
Thanks,
Iqbal Ahmad
Edited by: Iqbal Ahmad on Sep 15, 2008 6:31 PM

Hi Iqbal,
Hope you are doing good
Well, have a look at these links.
http://help.sap.com/saphelp_nw04/helpdata/en/91/4931eca9ef05449bfe272289d20b37/frameset.htm
This document, gives a detailed description.
https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/f570c7ee-0901-0010-269b-f743aefad0db
Hope this helps.
Cheers,
Sandeep Tudumu

SAP BEST PRACTICES FOR CRM for 5.0 version.

Hi ,
Any can give me SAP BEST PRACTICES FOR CRM for 5.0 version.
Any link is also fine.
thanks & Regards
Prajith P
Moderation: Please check SAP Service Marketplace Download Area to obtain this copyrighted material
Edited by: Joaquin Fornas on Nov 8, 2011 3:50 PM

Hi
I sent to u r email id plz check
Reward Points if helpful
Venkat

Cisco Network 2009 - Best practices for migrating previous versions of cisco unified communications manager to cucm 7.1

Does anybody have a copy of the above referenced presentation that you could send me.
Thanks in advanced.
The presentation can be purchased at the following site:
http://www.scribd.com/doc/33211957/BRKVVT-2011-Best-Practices-for-Migrating-Previous-Versions-of-Cisco-Unified-Communications#archive
but felt I ask one of my peeps first.
Thanks in advanced.
Dennis

Hi Dennis,
Well..let's give this a try
Cheers!
Rob

Microsoft best practices for patching a Cluster server

Good morning! I was wondering if you had any web resources (Webcasts) or whitepapers on Microsoft best practices for patching a Cluster server? I will list what I seen online; the third one was very good:
Failover Cluster Step-by-Step Guide: Configuring a Two-Node File Server Failover Cluster
http://technet.microsoft.com/en-us/library/cc731844(v=ws.10).aspx
Failover Clusters in Windows Server 2008 R2
http://technet.microsoft.com/en-us/library/ff182338(v=ws.10)
Patching Windows Server Failover Clusters
http://support.microsoft.com/kb/174799/i

Hi Vincent!
I assume this step-by-step guide can also be used if you have more then 2 nodes, as long as you make sure majority of nodes are up (and quorum disk is available).
I just had a strange experience during maintenance of 2 nodes (node nr 7 and nr 8) in a 8 node hyper-v cluster R2 SP1 with CSV. I used SCVMM2012 to put the nodes in maintenance mode. (live migrating all resources to other nodes.) I then look in "Failover cluster
manager" to check that the nodes had been "Paused". And yes everything was just fine. I then did windows update and restartet, no problem. But after restart I wanted to run PSP (HP's update utility) to update some more drivers,software etc. During this PSP
update, node nr 02 suddenly failed. This node is not even a HP Blade, so I'm not sure how, but I know network NIC drivers and software where updated from PSP. So my question is:
Does changes in "Network Connections" on nodes in "Pause" mode affect other nodes in the cluster?
The network are listed as "Up" during Pause mode, so the only thing I could think of is that during PSPs driver/software update, NICs on node 07 and 08 were going down and up differently somehow making Node 02 fail.
So now during maintenance (Vendor driver/software/firmware updates, not MS Patches) I first put the node in "Pause" mode then I stop cluster service, (and change it to disabled) making sure nothing can affect the cluster.
Anders

BEST PRACTICES FOR CREATING DISCOVERER DATABASE CONNECTION -PUBLIC VS. PRIV

I have enabled SSO for Discoverer. So when you browse to http://host:port/discoverer/viewer you get prompted for your SSO
username/password. I have enabled users to create their own private
connections. I log in as portal and created a private connection. I then from
Oracle Portal create a portlet and add a discoverer worksheet using the private
connection that I created as the portal user. This works fine...users access
the portal they can see the worksheet. When they click the analyze link, the
users are prompted to enter a password for the private connection. The
following message is displayed:
The item you are requesting requires you to enter a password. This could occur because this is a private connection or
because the public connection password was invalid. Please enter the correct
password now to continue.
I originally created a public connection...and then follow the same steps from Oracle portal to create the portlet and display the
worksheet. Worksheet is displayed properly from Portal, when users click the
analyze link they are taken to Discoverer Viewer without having to enter a
password. The problem with this is that when a user browses to
http://host:port/discoverer/viewer they enter their SSO information and then
any user with an SSO account can see the public connection...very insecure!
When private connections are used, no connection information is displayed to
SSO users when logging into Discoverer Viewer.
For the very first step, when editing the Worksheet portlet from Portal, I enter the following for Database
Connections:
Publisher: I choose either the private or public connection that I created
Users Logged In: Display same data to all users using connection (Publisher's Connection)
Users Not Logged In: Do no display data
My question is what are the best practices for creating Discoverer Database
Connections.
Is there a way to create a public connection, but not display it in at http://host:port/discoverer/viewer?
Can I restrict access to http://host:port/discoverer/viewer to specific SSO users?
So overall, I want roughly 40 users to have access to my Portal Page Group. I then want to
display portlets with Discoverer worksheets. Certain worksheets I want to have
the ability to display the analyze link. When the SSO user clicks on this they
will be taken to Discoverer Viewer and prompted for no logon information. All
SSO users will see the same data...there is no need to restrict access based on
SSO username...1 database user will be set up in either the public or private
connection.

You can make it happen by creating a private connection for 40 users by capi script and when creating portlet select 2nd option in Users Logged in section. In this the portlet uses there own private connection every time user logs in.
So that it won't ask for password.
Another thing is there is an option of entering password or not in ASC in discoverer section, if your version 10.1.2.2. Let me know if you need more information
thnaks
kiran

Best Practice for Downgrading J2EE/Portal Patch Version

Similar Messages

Maybe you are looking for