Thursday, July 18, 2013

IPM 10g migration issue!

We have been working on a project to migrate IPM 10g to 11g.For moing to 11g we need to install the Migration tool MCU .This can be installed on 10.1.3.6 IPM.So we upgraded it first which is simple process and applied the MCU patch .After that when we try to migrate we get

Issue:
Method not found: 'Int32 Stellent.IBPM.Interop.Imaging.DocTk.ISubDocument.get_ObjectId()'
As usual it was something new so we worked with support which has some amazing people.

Finally this they asked us to reapply the MCU patch 15868093 .This did not help.

Finally found that ,

Solution:

On the box where you are trying to use the migration tool :

--  You will need to replace the existing Internal.IBPM.Interop.Imaging.DocTk.DLL file
in the c:\Windows\Assembly folder (GAC) with the new one in the migration tool patch
"p16933027_10136_WINNT.zip":

Navigate to c:\windows\assembly and locate the file Internal.IBPM.Interop.Imaging.DocTk.DLL.
Right-click on this file and select "Uninstall".

===============================================================================
Drag and drop the new Internal.IBPM.Interop.Imaging.DocTk.DLL.

from the patch path : Oracle Imaging and Process Management\Imaging and Process Management\DSMS\
into the c:\windows\assembly

NOTE: You will need to drag and drop into the actual content window pane of c:\windows\assembly,
as this is how interops are registered in Windows. This is best accomplished by opening two explorer
windows to do the drag.

Drag from the patch zip file path
----  Oracle Imaging and Process Management\Imaging and Process Management\DSMS\Internal.IBPM.Interop.Imaging.DocTk.DLL

Then drop the file into the right-hand window pane of c:\windows\assembly.
=================================================================================


Restart your service(s)


This fixed the issue and now we are ready to setup 11g to kick start the migration.

Wednesday, April 3, 2013

The files created in the ODI servers with OS users are having the permission -rw-r-----

We recently got an issues where implementer said that when he created files from ODI agent ,he got issues like file had -rw-r-----(640) permission only .We checked that at OS level teh usmask was set to 022.But we were wondering then from where was agent picking up the umask value.It seems like the umask is explicitly set on startWebLogic.sh and startNodeManager.sh .We need to fix this to fix the issue.


-bash-3.2$ grep umask startWebLogic.sh
umask 037

-bash-3.2$ grep umask startNodeManager.sh
umask 027

So we need to change umask to 022 in both locations and restart services to fix the issues.Same goes with weblogic log file permissions.

Tuesday, March 26, 2013

WebCenter Custom Portal domain extension ,Custom Portal Component Schemas Are Not Displayed

We were today extending a webcenter customer's domain as they wanted a custom portal to deploy their portal application.While were following Doc ID 1339004.1 to do the same.We found that we couldn't proceed to 
  • Configure JDBC Component Schema screen

  • We found that its a known issue as per Doc ID 1527347.1

    Also if you don't find this screen, just click next twice and voila you get the screen.

    Friday, March 22, 2013

    Cannot Start OIM After Applying WLS PSU patches


    Issue:Unable to start OIM after patch application.
    =====================================================
    
    
    To see the stack trace for thread that is initializing this, set the logging level of oracle.adf.share.ADFContext to FINEST>
    <Mar 22, 2013 1:49:51 AM CDT> <Error> <Deployer> <BEA-149205> <Failed to initialize the application 'oim [Version=11.1.1.3.0]' due to error java.security.AccessControlException: access denied (oracle.security.jps.service.credstore.CredentialAccessPermission context=SYSTEM,mapName=oim,keyName=OIMSchemaPassword read).
    java.security.AccessControlException: access denied (oracle.security.jps.service.credstore.CredentialAccessPermission context=SYSTEM,mapName=oim,keyName=OIMSchemaPassword read)
            at java.security.AccessControlContext.checkPermission(AccessControlContext.java:374)
            at java.security.AccessController.checkPermission(AccessController.java:546)
            at oracle.security.jps.util.JpsAuth$AuthorizationMechanism$3.checkPermission(JpsAuth.java:436)
            at oracle.security.jps.util.JpsAuth.checkPermission(JpsAuth.java:496)
            at oracle.security.jps.util.JpsAuth.checkPermission(JpsAuth.java:519)
            Truncated. see log file for complete stacktrace
    Caused By: java.security.AccessControlException: access denied (oracle.security.jps.service.credstore.CredentialAccessPermission context=SYSTEM,mapName=oim,keyName=OIMSchemaPassword read)
            at java.security.AccessControlContext.checkPermission(AccessControlContext.java:374)
            at java.security.AccessController.checkPermission(AccessController.java:546)
            at oracle.security.jps.util.JpsAuth$AuthorizationMechanism$3.checkPermission(JpsAuth.java:436)
            at oracle.security.jps.util.JpsAuth.checkPermission(JpsAuth.java:496)
            at oracle.security.jps.util.JpsAuth.checkPermission(JpsAuth.java:519)
            Truncated. see log file for complete stacktrace
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    Patch applied:
    --------------
    Patch 14736140: 10.3.5.0.6 Patch Set Update (PSU) for WebLogic Server 10.3.5.0
    
    
    Found couple of notes on oracle to fix this, but they referred to different patches and versions of OIM.This is how i fixed it.
    
    
    
    
    Solution:
    =========
    1. Stop the servers
    
    
    2. On each node (if is cluster), add the following in DOMAIN_HOME/config/fmwconfig/system-jazn-data.xml:
    
    
    <grant>
      <grantee>
        <codesource>
          <url>file:${wls.home}/../../patch_wls1035/patch_jars/*</url>
        </codesource>
      </grantee>
      <permissions>
        <permission>
          <class>oracle.security.jps.service.credstore.CredentialAccessPermission</class>
         <name>context=SYSTEM,mapName=oim,keyName=*</name>
         <actions>read,write</actions>
        </permission>
       </permissions>
    </grant>
    
    3.From the below location
    
    Oracle_home/wlserver_10.3/server/lib
    
    in the file weblogic.policy
    
    add the below lines
    
    grant codeBase "file:/patch_wls1035/patch_jars/*" {
      permission java.security.AllPermission;
    };
    
    Its best to add full path in step 3, as above didnot work for me and after making it absolute path,OIM started up.
    (grant codeBase "file:<MW_HOME>/patch_wls1035/patch_jars/*")
    
    4.Start the servers.
    
    
    

    Thursday, February 7, 2013

    RJVM has already been shutdown


     ###<Feb 7, 2013 5:59:50 AM GMT> <Info> <JMS> <kkkkk> <bo-server03513> <[ACTIVE] ExecuteThread: '2' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1360216790795> <BEA-040507> <The JMS SAF forwarder failed to connect to the remote destination "t3://abc.xyz:7003/jms/EJournalImport", because of javax.naming.CommunicationException [Root exception is java.rmi.UnmarshalException: RJVM has already been shutdown; nested exception is:
     java.io.IOException: RJVM has already been shutdown]
     at weblogic.jndi.internal.ExceptionTranslator.toNamingException(ExceptionTranslator.java:74)
     at weblogic.jndi.internal.WLContextImpl.translateException(WLContextImpl.java:470)
     at weblogic.jndi.internal.WLContextImpl.lookup(WLContextImpl.java:426)
     at weblogic.jndi.internal.WLContextImpl.lookup(WLContextImpl.java:411)
     at weblogic.jms.forwarder.Forwarder.connectTarget(Forwarder.java:416)
     at weblogic.jms.forwarder.Forwarder.reconnect(Forwarder.java:246)
     at weblogic.jms.forwarder.Forwarder.timerExpired(Forwarder.java:311)
     at weblogic.timers.internal.TimerImpl.run(TimerImpl.java:273)
     at weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:528)
     at weblogic.work.ExecuteThread.execute(ExecuteThread.java:209)
     at weblogic.work.ExecuteThread.run(ExecuteThread.java:178)
    Caused by: java.rmi.UnmarshalException: RJVM has already been shutdown; nested exception is:
     java.io.IOException: RJVM has already been shutdown
     at weblogic.rmi.cluster.ClusterableRemoteRef.invoke(ClusterableRemoteRef.java:360)
     at weblogic.rmi.cluster.ClusterableRemoteRef.invoke(ClusterableRemoteRef.java:259)
     at weblogic.jndi.internal.ServerNamingNode_1035_WLStub.lookup(Unknown Source)
     at weblogic.jndi.internal.WLContextImpl.lookup(WLContextImpl.java:423)
     ... 8 more
    Caused by: java.io.IOException: RJVM has already been shutdown
     at weblogic.rjvm.ResponseImpl.unmarshalReturn(ResponseImpl.java:234)
     at weblogic.rmi.cluster.ClusterableRemoteRef.invoke(ClusterableRemoteRef.java:348)
     ... 11 more
    Caused by: java.io.IOException: RJVM has already been shutdown
     at weblogic.rjvm.RJVMImpl.addPendingResponse(RJVMImpl.java:513)
     at weblogic.rjvm.RJVMImpl.send(RJVMImpl.java:900)
     at weblogic.rjvm.MsgAbbrevOutputStream.flushAndSend(MsgAbbrevOutputStream.java:394)
     at weblogic.rjvm.MsgAbbrevOutputStream.sendRecv(MsgAbbrevOutputStream.java:404)
     at weblogic.rjvm.BasicOutboundRequest.sendReceive(BasicOutboundRequest.java:109)
     at weblogic.rmi.cluster.ClusterableRemoteRef.invoke(ClusterableRemoteRef.java:345)
     ... 11 more


    The solution was strange and found on the internet.


    The problem is probably a bad or slow DNS lookup on the IP address 192.100.88.1Indeed, the weblogic server tries to connect to the admin ListenAddress and did a double resolution 
    Name => Address
    Address => name
    To avoid this problem, it is better not to name fqdn in ListenAddress, but to put the listening IP address.We changed hostname to ip from admin console and bounced managed server.