AL-Infotech

Have you ever tried to update an SAP NetWeaver 2004 Java Application Server with multiple instances? If yes, how did you patch the dialog instances (DIs)? I guess you ran the update tool SAPinst on every dialog instance host. SAPinst actually doesn’t do much about the DIs than just copying the new kernel binary files to the DI-individual executable directories. The Java applications running on top of the runtime engine will be synchronized out of the central database instance during the next startup. Thus applications are updated when the central instance is being updated. (That’s why the update of the central instance lasts longer.) You might have wondered why no automatic synchronization with kernel binaries can be done? Well, until the SP Stack 18 this function was not provided due to some architectural limitations with the SAP NetWeaver 2004 Java server. In SAP NetWeaver 2004s, this feature is automatically configured by the installation of dialog instances. There is another blog which deals with the kernel distribution on SAP NetWeaver 2004s Java application server. SAP has now down-ported this feature to NW04 and delivers the configuration service which is integrated in the patch tool (SAPinst) for NW04 Java engine with the SP stack 19.
Like in a NetWeaver 2004s Java system, the automated kernel distribution works with the kernel program SAPCPE which checks, and if necessary, copies newer version of the kernel binary files from the central kernel directory to the instance-individual executable directories. Die individual instances start from their own executable directories. You need perform the configuration service which comes with SAPinst of the SP level 19 or higher only once to enable SAPCPE. As the screen-shot below shows, you have to start SAPinst on the central instance host and choose the service Enable Automated Kernel Distribution Using SAPCPE. With some further specifications the function is configured for all future updates (You can download the Support Package Stack Guide for NW2004 for detail information about the configuration steps). Every time when the kernel binaries on the central instance have been updated, SAPCPE will replicate them to the dialog instances upon restart.

You should also take following restrictions or conditions that are significant for the proper functioning of the kernel replication into account:

• The automated kernel replication and the configuration service for SAPCPE works only in Java-only systems, not in double-stack systems (ABAP+Java).
• The Java-system cluster must be homogeneous. Dialog instances running on hosts with operation systems other than the central instance require different versions compiled for the individual operating systems. Due to file format incompatibility, kernel files for different operating systems are located on appropriate hosts. Therefore SAPCPE cannot simply replicate the version from the central instance.
• All instances must be at least of SPS17. As mentioned earlier, the kernel replication was impossible for NW04 due to some architectural limitations. With SPS17, these limitations are remedied. Don’t be confused with the replication configuration service delivered with SPS19. The configuration service is included in patch tool (SAPinst) of SPS19 and above, but runtime systems of SPS17 already have the appropriate architecture to be configured for the automated replication. Therefore you can use the configuration service included in SPS19 to configure an SPS17 Java system.

I hope, the kernel replication function eases your daily work a little

 

 

 

First, if your going to Tech Ed in Amsterdam next week, please stop by the Web Dynpro basics course (CD155) — I’ll be conducting a hands-on session on Web Dynpro-Portal integration. Not to be missed — I’ll be giving out candy to the developers who finish first or ask the most interesting questions.

Second, I’m sorry it took so long to return to blogging on portal development (in the middle of my series on the PCD).

Finally, let’s discuss PCM.

PCM (Portal Content Model) has existed for a while, but rarely is it discussed. PCM-related interfaces are used by portal developers, but usually without any understanding of what PCM is.

PCM is a set of interfaces that all portal objects must implement — at least if they want to be displayed in the Portal Catalog. The administration tools — most notably the Portal Content Studio — requires all portal objects to provide a few basic interfaces so that it can display them in the Portal Catalog.

The main provider until now, of course, has been the PCD, but there may be other providers of portal objects. So the portal needed a set of interfaces for portal objects that was not dependent on the PCD.

The interface that all portal objects must provide is IAdminBase, from which you can obtain the following interfaces:

• IAttributeSet: Provides information on the attributes of the object, so these can be displayed in the Property Editor.
• IPermission: Provides information about who has permission to modify and delete the object.
• ICatalogNode: Provides additional information for displaying the object in the Portal Catalog, such as the URL for the image to display as the object icon.

To get a the IAdminBase of a portal object, just specify the administration aspect when performing a lookup for the object, as in the following example:


   Hashtable env = new Hashtable();

   env.put(Context.INITIAL_CONTEXT_FACTORY,
      IPcdContext.PCD_INITIAL_CONTEXT_FACTORY);
   env.put(Constants.REQUESTED_ASPECT, PcmConstants.ASPECT_ADMINISTRATION);
   env.put(Context.SECURITY_PRINCIPAL, request.getUser());

   InitialContext iCtx = null;
   String myRole = "portal_content/MyContent/Corporate";

   try {

      iCtx = new InitialContext(env);
      IAdminBase myAdmin = (IAdminBase)iCtx.lookup(myRole);
      IPermission myIview = (IPermission)myAdmin.getImplementation(IAdminBase.PERMISSION);

      String[] myPermissions = myIview.getAllPermissions();
      for (int i = 0; i < myPermissions.length; i++) {
         response.write(myPermissions[i] + "
");
      }
   }
   catch (Exception e) { }


The above code gets an IAdminBase for the specified portal object, then gets an IPermission object from this, and displays all the permissions assigned to this object.

Just a side note: Permissions are a little tricky, as there are PCD permissions, PCM permissions, and you could assign your own permissions to an object. More on this in my next blog.

All of this, including how to the key interfaces, is described in painstaking detail at Accessing the PCD.

Hopefully, I’ll see you all at Tech Ed.