Important Lookups that you might need to customize

Some important lookups you might need to customize

Lookup.Organization.Type

This is a 1-D Lookup meaning that each Code Key normally has a matching Decode value
The OOTB values are: Company, Branch, Department.  If you need to add an organization type, such as Application, Division, etc., add it here on both sides.  It will now be available as an Organization Type.

Lookup.Users.Role

This is a 2-D Lookup meaning that the Code Key is stored in the database but the Decode value shows up in the UI Elements.  OOTB this lookup contains:
Full-Time = Full-Time Employee
Part-Time = Part-Time Employee
Temp = Temp
Intern = Intern
Consultant = Consultant
Contractor = Contractor

I believe this is correct but not 100% sure.  Add elements as you need.

Sharing log files with users who are not in the oinstall group

Sometimes a client wants to be able for a user to view log files for an Oracle application.  There are many ways to do this:

1. Give the user sudo rights to the oracle user.
2. Put the user in the oinstall group (assuming that was the default group used in the installation for the oracle user)
3. Open up the umask to 0022 so that any user can read the files.
4. Do the following:

First, you need to give read access to all of the folders in the chain.  Let's say you have a middleware home of:

/u01/oracle/products/middleware

and in there you have a domain home of

$MW_HOME/user_projects/domains/oim_domain

and in there you have a server

$DOMAIN_HOME/servers/oim_server1

In this case every folder between /u01 and oim_server1 would have to be granted 755 privileges.  It is easy enough to just go through and chmod each folder in order and then check from a user who has not been granted any of 1-3.

Next, the umask in the .bash_profile does have to be 0027 or better for people to read the files if they are in the correct group.

To make this work here is what needs to happen:

As root, execute the command:
# groupadd oshare
(I made up that group name oshare but you can call it whatever you want).
# usermod -a -G oshare oracle
# usermod -a -G oshare username
(username is the user you want to share files with)
# cd <that oim_server1 folder>
# chown -R oracle:oshare logs
# chmod -R 2755 logs

That should do it.  I have not tested this.

To reverse this go back and perform:
# chown -R oracle:oinstall logs

If you want the user to be able to delete files and not just read them, change the 2755 above to 2775.
You will have to do this in any log folder you want to share.  I would not advise sharing any other folder.  This does include the ADR folders.

OIM11gR2 Using the old Thor interfaces

Sometimes you need to use the old Thor interfaces for getting information from the system. Lookups are one of these items, and that will be the example used here.

Also see my other posting OIM How to pull an IT Resource Parameter

Import the resource:

import Thor.API.Operations.tcLookupOperationsIntf;

Define the interface (spell something differently, in this case I used lower case L in lookup):

tcLookupOperationsIntf tclookupOperationsIntf =null;

Get the service:

tclookupOperationsintf = Platform.getService(tcLookupOperationsIntf.class);

Optionally you can do this all in one line.  You should null check the returned value.

Here's a completed task that just checks to see if a value is in a list:

Thor.API.tcResultSet rs=null;
try {
  rs=tclookupOperationsIntf.getLookupValues(validAccountLookup);
  int rowcount=rs.getRowCount();
  for (int irow=0; irow < rowcount; ++irow) {
    rs.goToRow(irow);
    String codeKey=rs.getStringValue
      ("Lookup Definition.Lookup Code Information.Code Key");
    String decode=rs.getStringValue
      ("Lookup Definition.Lookup Code Information.Decode");
    if (appInstanceName.equals(codeKey)) {
      logger.logp(Level.FINE, getClass().getName(), methodName,
        "Found "+appInstanceName+" in row "+irow+", returning true");
      return true;
    }
  }
}

I left out all of the checks and catches, just showing functional code.

Oracle OIM11gR2 finding the uploaded jar files

Thanks again to my colleagues for pointing this out.

The jar files you uploaded through UploadJars.sh are contained in the OIMHOME_JARS table.  It doesn't appear to use the update date so you will need to download the BLOB and SHA1 it to see if it is exactly what you expected to see.

Here's a hint.  Don't use a version numbered file for Java Tasks jar files.  You basically have to maintain that version number forever.  Better to use the non-version numbered jar file for deployment and use SHA1 to check a version numbered copy against what you have deployed.

Update: you can use a version numbered jar file for Java Tasks jar files.  The only issue is that you will see references to the older versions in the task adapters and you may be confused.  It is not an issue and the class loader will go to the new jar file.

Oracle Diagnostic Logging on Weblogic - Manual Modifications

My last post on this subject involved setup.  If you are a situation where you have classes in packages such as com.mycompany.subject.specificarea and you log into the ODL logging area, you can't easily search on com.  This is why I suggested your class packages are something more like mycompany.subject.specificarea leaving off the com part.

You can search on you mycompany name in the ODL log configuration page, but you won't get the high level box like if you search on com.  And so you have to change the logging level of each individual class, and if the class you are developing has never been called, it will not be in the list.  How to fix?

Start by setting a persistent log level for one of the classes in your package structure.  Don't do it for a second or more, that's overkill.  Next, save and log out of EM.

Next, log into your server and navigate to the domain for your admin server.  Then navigate to config/fmwconfig/servers/oim_server1 (or whatever your server name is) and then edit logging.xml

Find the section which contains your class name that you just modified.  Trim back the name as far back as you desire.  Generally I leave the com.mycompany

Log levels in this file are:

INCIDENT_ERROR:1 (SEVERE+100)

ERROR:1 (SEVERE)
WARNING:1 (WARN)
WARNING:32
NOTIFICATION:1 (INFO)
NOTIFICATION:16 (CONFIG)
NOTIFICATION:32
TRACE:1 (FINE)
TRACE:16 (FINER)
TRACE:32 (FINEST)

Restart the managed server.

OIM11gR2 running design console on Windows machine

To run the design console on Windows:

Make sure you have a version of JRockit 1.6 on your Windows machine and have that path in your JAVA_HOME environment variable.

On the OIM machine, cd to $OIM_ORACLE_HOME which should be defined as $MW_HOME/Oracle_IDM1
Next, zip up the designconsole folder like this:

$ zip -r ~/designconsole.zip designconsole

Copy that file to your windows machine into a folder that reflects the environment it will connect to.

Unzip the file so it creates a designconsole folder with the xlclient.cmd file in that folder.

Edit the xlclient.cmd file.
Change the first part of the command to read "%JAVA_HOME%\bin\java"

Change the HOME_DIR to read -DXL.HomeDir=.
That's a single dot to indicate the current folder.

Change the auth to read:
-Djava.security.auth.login.config=config\authwl.conf

Save the file.

Now go back to the workstation and copy the following files to the ext folder:

$MW_HOME/oracle_common/modules/oracle.jrf_11.1.1/jrf-api.jar

At the very end of the classpath.bat file, there is a reference to the oracle_common/modules/jrf folder associated with the jrf-api.jar file.  Fix that so it references the ext folder.

This should allow you to double-click on the xlclient.cmd file to start the design console.

Oracle database scripts I like to use:

This blog is for my reference in quickly getting to Oracle database scripts I like to use.  Some of these are taken from other websites either verbatim or customized to my own preferences.

show_profiles.sql

clear breaks
set linesize 120
set pagesize 10000
select * from dba_profiles order by profile, resource_name;

show_users.sql

clear breaks
set linesize 120
set pagesize 10000
select username, profile, account_status from dba_users;

show_tablespaces.sql

clear breaks
SET linesize 130
SET pagesize 60
break ON tablespace_name skip 1
col tablespace_name format a15
col file_name format a50
col tablespace_kb heading 'TABLESPACE|TOTAL KB'
col kbytes_free heading 'TOTAL FREE|KBYTES'
SELECT dd.tablespace_name tablespace_name, dd.file_name file_name, dd.bytes/1024 TABLESPACE_KB, SUM(fs.bytes)/1024 KBYTES_FREE, MAX(fs.bytes)/1024 NEXT_FREE
FROM sys.dba_free_space fs, sys.dba_data_files dd
WHERE dd.tablespace_name = fs.tablespace_name
AND dd.file_id = fs.file_id
GROUP BY dd.tablespace_name, dd.file_name, dd.bytes/1024
ORDER BY dd.tablespace_name, dd.file_name;

show_datafiles.sql

clear breaks
set linesize 120
set pagesize 10000
col file_name format a70
col tablespace_name format a20
SELECT file_name, tablespace_name, ROUND(bytes/1024000) MB
FROM dba_data_files
ORDER BY 1;

show_freespace.sql

clear breaks
set linesize 120
set pagesize 10000
SELECT df.tablespace_name TABLESPACE, df.total_space TOTAL_SPACE,
fs.free_space FREE_SPACE, df.total_space_mb TOTAL_SPACE_MB,
(df.total_space_mb - fs.free_space_mb) USED_SPACE_MB,
fs.free_space_mb FREE_SPACE_MB,
ROUND(100 * (fs.free_space / df.total_space),2) PCT_FREE
FROM (SELECT tablespace_name, SUM(bytes) TOTAL_SPACE,
      ROUND(SUM(bytes) / 1048576) TOTAL_SPACE_MB
      FROM dba_data_files
      GROUP BY tablespace_name) df,
     (SELECT tablespace_name, SUM(bytes) FREE_SPACE,
       ROUND(SUM(bytes) / 1048576) FREE_SPACE_MB
       FROM dba_free_space
       GROUP BY tablespace_name) fs
WHERE df.tablespace_name = fs.tablespace_name(+)
ORDER BY fs.tablespace_name;

show_tables.sql <- uses a parameter

clear breaks
set linesize 120
set pagesize 10000
select owner, table_name, tablespace_name
from dba_tables
where tablespace_name='&1';

Here is a great link on formatting: 

And another link on selecting the first few rows: 

OIM11gR2 Setting a specific user as a system administrator

Technique to set a user OIMADMIN to have the same access as XELSYSADM.
OIMADMIN is just an example.

Step 1: Set the user's USR_TYPE to "End-User Administrator"

update usr set usr_type='End-User Administrator' where usr_login='OIMADMIN';
commit;

Step 2: Add the user to the System Administrators "Admin Role"

In the Identity Webapp, logged in as xelsysadm, navigate to Organizations and search on the organization called "Top".
The first role in the Top organization is System Administrators.  Select it.
Explicitly add the OIMADMIN user to this role by direct assignment using the dialog provided.

Be sure to check the sub-orgs and Apply

That is it.   You should see SYSTEM ADMINISTRATORS in the Roles tab of the view user page.

Packaging an incident report on a weblogic managed server

How to package an incident report:

View this URL:

http://docs.oracle.com/cd/E27559_01/core.1112/e28516/diagnostics.htm#ASADM11171

Quick setup:

Here is a little script to list the OIM incidents (for OIM):

#!/bin/sh
# Lists time and problem for incidents on OIM
PWD=`pwd`
now=`date`
tf=/tmp/litmp$$
cd $DOMAIN_HOME/servers/oim_server*/adr/diag/ofm/oim_domain/oim_server*
echo "Searching incident reports"
find incident/ -type d -name 'incdir_*' -print > $tf
for each in `cat $tf`
do
  echo " "
  head -4 $each/readme.txt
done

Find the incident you want.

Have this script setenv_adr handy and source it:

ORACLE_HOME=$MW_HOME/wlserver_10.3/server/adr
export ORACLE_HOME
LD_LIBRARY_PATH=$ORACLE_HOME
export LD_LIBRARY_PATH
PATH=$PATH:$ORACLE_HOME

Next run adrci and copy in the following:

SET BASE <use your MW_HOME folder>/user_projects/domains/oim_domain/servers/oim_server1/adr
SET HOMEPATH diag/ofm/oim_domain/oim_server1

Of course use your own folder names and server names.  Then enter:

IPS CREATE PACKAGE INCIDENT incident_number

IPS ADD FILE filespec PACKAGE package_number 

IPS GENERATE PACKAGE # in /tmp

Working with the Oracle Diagnostic Logging on Weblogic

How to use the ODL effectively in the following:

Event Handlers
Scheduled Tasks
ICF Connectors

First, use the following classes in your code:
java.util.logging.Logger
java.util.logging.Level

You do not have to use log4j-xxx.jar it is not needed.

Second, and this is very important, if you CAN, do not begin your package name with com, rather use something unique like edu for colleges or your company abbreviation.  This will make it easier to do the configuration in the Enterprise Manager.

Next, in your code, use the following techniques:
1) In your class definition, create a private static final Logger called logger and initialize it with the class like this:
private static final Logger logger = Logger.getLogger(MyClass.class.getName());

2) In each method specify a String with the method name such as:
String methodName="execute";

3) At the beginning of each method use:
logger.logp(Level.FINE, getClass().getName(), methodName, "Entering");

4) Optionally, at the end of each method use:
logger.logp(Level.FINE, getClass().getName(), methodName, "Exiting");


5) For the rest of your output statements, use:
logger.logp(Level.FINE, getClass().getName(), methodName,
   "whatever you want to say in your message");

For these types of statements the following are available:
Level.SEVERE         Level.WARNING      Level.INFO
Level.FINE               Level.FINER             Level.FINEST

That's it for the code.

In Weblogic's Enterprise Manager, open the deployment where you have placed your code, Nav to this with WebLogic Domain -> domain name and select the managed server.

You will see the managed server name (it needs to be up with the green up arrow) and below that will read WebLogic Server and show a down arrow.  Select the down arrow and nav to Logs -> Log Configuration.

In here you see 3 tabs, Log Levels, Log Files, and QuickTrace.  Select Log Levels, View Runtime Loggers, and search on your class name.

Find your class name.  The default log level is normally WARNING.  Choose wisely the class or package you want to modify, and set the level to the highest level you wish to see.  Scroll to the bottom of the screen and check the "Persist log level state across component restarts" and then click "Apply".  Your logger is now set to go to the diagnostic.log file.

If you want to have your data go to a separate set of log files, go to the Log Files tab and select the odl-handler Handler Name, then click on "Create Like...", and create a new Handler.  Give it a cool name and change the configuration to use a different file name pattern than -diagnostic.  Save this and then assign your classes to it.  Done.

OIM How to pull an IT Resource Parameter

Inputs will be the IT Resource Name and the IT Resource Parameter Name

Define the following:
private tcITResourceDefinitionOperationsIntf itResDefOp=null;
private tcITResourceInstanceOperationsIntf itResInstOp=null;
private    long itResourceKey = 0L;

Next, in some module pull the Ops:

itResDefOp=Platform.getService(tcITResourceDefinitionOperationsIntf.class);
itResInstOp=Platform.getService(tcITResourceInstanceOperationsIntf.class);

Define a search and get the itResourceKey

Map searchFor = new HashMap();
searchFor.put("IT Resources.Name", itResourceName);
try {
    tcResultSet results = 
        itResInstOp.findITResourceInstances(searchFor);
    if (results.getRowCount() == 1) {
        results.goToRow(0);
        itResourceKey = 
            results.getLongValue("IT Resources.Key");
    } else {
        searchFor.clear();
        results = 
            itResInstOp.findITResourceInstances(searchFor);
        for (int i = 0; i < results.getRowCount(); i++) {
            results.goToRow(i);
            if (results.getStringValue("IT Resources.Name")
                .equalsIgnoreCase(itResourceName)) {
                itResourceKey = 
                     results.getLongValue("IT Resources.Key");
                break;
            }
        }
    }
}
catch (Exception ex) {
    ;
}

Finally, pull the parameter value:

try {
    tcResultSet paramSet= itResInstOp
       .getITResourceInstanceParameters(itResourceKey);
    int numParams=paramSet.getRowCount();
    if (numParams < 1) {
        ;  // Do something here it's not found
    }
    for (int iparam=0; iparam < numParams; ++iparam) {
        paramSet.goToRow(iparam);
        String paramName=paramSet
           .getStringValue("IT Resources Type Parameter.Name");
        if(paramName
           .equalsIgnoreCase("WhatYouAreSearchingFor")) {
            ResultValue=paramSet
               .getStringValue("IT Resource.Parameter.Value");
        }
    }
}
catch (Exception e) {
    ;
}

Reduce Weblogic startup time

This one is from my coworker:

In the jre/lib/security/java.security file for the JDK you are running WLS under look for this line:

securerandom.source=file:/dev/urandom

and change it to:

securerandom.source=file:/dev/./urandom

It cuts the startup time in half.  It has to do with a bug where Java interprets /dev/urandom as /dev/random which is a really slow RNG in Linux.  Adding the /./ reference is a simple workaround and makes it go back to /dev/urandom as the RNG.

SSL Keytool Mojo

Keytool setup: put the following into your .bash_profile:

JAVA_KEYSTORE="-keystore $JAVA_HOME/jre/lib/security/cacerts -storepass changeit"

DEMOTRUST_KEYSTORE="-keystore $WL_HOME/server/lib/DemoTrust.jks -storepass DemoTrustKeyStorePassPhrase"

This will make it easy to use keytool.  Then you can do:

keytool -list $JAVA_KEYSTORE

keytool -list $JAVA_KEYSTORE | grep rootca

keytool -delete -alias rootca $JAVA_KEYSTORE

keytool -import -alias rootca -file <filename> $JAVA_KEYSTORE

OIM How-To set the xelsysadm password to never expire

To set the xelsysadm password to never expire, log into the database as the OIM schema owner and execute:

update usr set usr_pwd_warn_date=null, usr_pwd_expire_date=null,

usr_pwd_never_expires='1' where usr_login='XELSYSADM';

commit;

You can do this for any user.

How-To set the OIM database accounts to never expire

Because Oracle has put reasonable security limits into the default profile of the 11g database, when the OIM RCU runs it put the schema accounts into the default profile.  These account passwords will expire if you do not explicitly set them to not expire.  Assuming a Prefix of EDG the procedure will look like this:

$ sqlplus / as sysdba

SQL> CREATE PROFILE SERVICE_ACCOUNT

2    LIMIT PASSWORD_LIFE_TIME UNLIMITED

3    FAILED_LOGIN_ATTEMPTS UNLIMITED;

Profile created.

SQL> ALTER USER EDG_MDS PROFILE SERVICE_ACCOUNT;

User altered.

SQL> ALTER USER EDG_OIM PROFILE SERVICE_ACCOUNT;

User altered.

SQL> ALTER USER EDG_SOAINFRA PROFILE SERVICE_ACCOUNT;

User altered.

SQL> ALTER USER EDG_OPSS PROFILE SERVICE_ACCOUNT;

User altered.

SQL> ALTER USER EDG_ORASDPM PROFILE SERVICE_ACCOUNT;

User altered.

​

If the user passwords are due to or already have expired, go through all 5 of them (as sysdba) and re-set the password by entering (example for user EDG_OIM):

SQL> ALTER USER EDG_OIM IDENTIFIED BY <password>

Where <password> is the password of record, or a new password if you want to make those changes

Some updates 2015-June:

Use this script to get the list of profiles:

clear breaks
set linesize 120
set pagesize 10000

select * from dba_profiles;

Use this script to get the list of users:
clear breaks
set linesize 120
set pagesize 10000

select username, profile, account_status from dba_users;

For some systems you may have additional users to add to the profile.

OIM11gR2 Testing Access Policies

When developing and testing access policies, the following guidelines are good advice to follow:

In the Scheduler, typically the Evaluate User Policies scheduled job runs every 10 minutes.

When testing access policies, it is a good idea to click the Disable button so that the job does not run on its schedule.  The job can then be executed using the Run Now button.

When modifying an Access Policy, if the Retrofit Access Policy flag is set to Yes, then every user will be re-evaluated, and if the user fits the policy, that user will have their POLICY_EVAL_NEEDED flag set to 1 in the USER_PROVISIONING_ATTRS table.  If you don't want every single user to be re-evaluated, then after modifying the access policy, execute an update query such as:

UPDATE USR_PROVISIONING_ATTRS SET POLICY_EVAL_NEEDED=0

and then when you are prepared to test a user, use a similar query such as:

UPDATE USR_PROVISIONING_ATTRS SET POLICY_EVAL_NEEDED=1 WHERE USR_KEY=2023

It's a good idea to review and document the user that you chose to test before and after the test.  To execute the access policy logic, just go back and run the Evaluate User Policies scheduled job.

OIM11gR2 finding a list of active plugins

To find a list of plugins in your environment

Log into the OIM schema account for your environment

Execute a SELECT * FROM PLUGINS to view all of the active plugins.

Execute a SELECT * FROM LATEST_PLUGINS to compare.

It is a good practice, when performing active updates to plugins in your development environment, to modify the version number each build, so you have a way to validate that your plugin was picked up by the system.  Another way to do this is to review the diagnostic log for the messages indicating that the plugin has been picked up.

OIM11gR2 finding the event handlers currently deployed

To find the list of event handlers in OIM11gR2

• Log into the OIM Enterprise Manager http://<site>:7001/em
• On the left display, expand the Identity and Access folder and then the OIM folder under that, and then select the oim(11.1.2.0.0) object under the OIM folder.
• On the right display, select the dropdown reading Oracle Identity Manager and release on the System MBean Browser.
• In the folder structure, find under Application Defined MBeans: oracle.iam, and expand the Server: oim_server1 folder.
• Continue expanding the Application: oim and IAMAppDesignMBean folders, to expose the ConfigQueryMBeanName.  Searching on this name may work but may yield multiple results.
• Select the Operations Tab and click on the getEventHandlers operation.
• In the query put the Entity you wish to search on (User for user event handlers) and the operation (Create, Modify, Delete typically) and click Invoke.
• The display will reveal the Stage, Order, Name, Location, and Conditional flag for each event handler.
• System event handlers will typically have their location prefaced by /metadata.
• Registered custom event handlers will typically have their location prefaced by /custom
• Properly constructed plugin handlers will typically have their location prefaced by Plugin:
• Continue documenting the handlers you wish to review and then after modification.