Making plugins easier to manage is simple. I have a prior post that is not as detailed but is still applicable. First, occasionally run this query against your database and export the results:
SELECT DISTINCT(ID) FROM PLUGINS ORDER BY ID ASC
This will give you a list of the current plugins you have. If you want to know more try this query:
SELECT ID,VERSION,NAME,TYPE FROM PLUGINS ORDER BY ID ASC, VERSION DESC
The second query will show if you have multiple versions. The system should pick the highest numbered version, but I do not trust that. IMHO, always keep just the latest copy of each plugin.
The second thing to do is to make the plugin utility easier to use. Here's how: Open the ant.properties file and make sure you have filled in the provided values. I use MW_HOME in these examples but they need to be your $MW_HOME, spelled out in the file.
wls.home=$MW_HOME/wlserver_10.3
oim.home=$MW_HOME/Oracle_IDM1/server
login.config=${oim.home}/config/authwl.conf
mw.home=$MW_HOME
Correction: ant does not pick up the environment variables
mw.home=/u01/app/oracle/fmw
wls.home=/u01/app/oracle/fmw/wlserver_10.3
oim.home=/u01/app/oracle/fmw/Oracle_IDM1/server
Third, add the next 3 lines to the same file:
OIM.Username=xelsysadm
OIM.UserPassword=<your password>
ServerURL=t3://yourservice.yoursystem.yourdomain:14000
CtxFactory=weblogic.jndi.WLInitialContextFactory
Then you just run ant -f pluginregistration.xml unregister
All you have to type in is the password for xelsysadm
and paste the full class name from the export you did in step 1.
For the file names when you are running ant -f pluginregistration.xml register
I copy the files into a /home/oracle/plugins folder and then use:
find ~/plugins -name '*plugin*' -print
And then copy the line with the full pathname before I run the ant script. Again I just enter the password for xelsysadm and then paste the filename.
Be sure to fully stop and restart all servers (no rolling restarts) to make the new plugins active. I have found that PurgeCache does not work.
Just a quick reminder when creating Event Handlers (not for Scheduled Tasks)
UserManager usrMgr=Platform.getService (UserManager.class);
is used when you need to query for user parameters, such as when an orchestration might change one field, and you need to fill in other fields from the USR table in order to provide some kind of an update. An example is Display Name, which, if only the Last Name is changed, you will want to retrieve the First and Middle Name fields in order to properly construct the Display Name.
Platform.getServiceForEventHandlers is used when you want to perform any kind of updates within an Event Handler. Example:
ProvisioningService provSvcUP = Platform.getServiceForEventHandlers(ProvisioningService.class,
null, "ADMIN","XXXHandler", null);
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.
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.
