A plugin is a module of code which can be run inside the OIM server. It contains Java classes which are executed along with metadata (plugin.xml) which identifies them. There are many types of plugins - the type is determined by the Java interface or abstract class the plugin implements/extends.
One of the core components of OIM is the orchestration engine. It processes create/update/delete transactions on core identity objects (e.g. User, Role, etc). Each orchestration process involves the execution of a sequence of event handlers, and each event handler is a plugin implementing oracle.iam.platform.kernel.spi.EventHandler. Many are shipped out-of-the-box, and you can write custom ones too. For example, you could install an event handler to run after (postprocess) the creation of any user.
However, there are also other types of plugins - for example, login name generation plugins (oracle.iam.identity.usermgmt.api.UserNamePolicy). Some of these plugins are actually called by the out-of-the-box event handlers. Event handlers are a very general API (they are similar in concept to database triggers) - they have a lot of power, but if you are not careful with that power you can destabilise your OIM environment. By contrast, other plugin interfaces perform one specific task only (such as generating a login name for a new user), and thus the risk from using them is much less. If you can solve your problem using some more specific type of plugin, do that in preference to using an event handler.
You will also find, that while some of these more specific plugin interfaces are called by out-of-the-box event handlers, others are not called by the orchestration engine at all, but instead by other components in OIM. For example, scheduled tasks are not run by the orchestration engine, but instead by the embedded Quartz scheduler. Custom scheduled tasks extend the oracle.iam.scheduler.vo.TaskSupport abstract class.
While every plugin needs the plugin framework metadata (plugin.xml), some specific types of plugins need additional metadata specific to that type. For example, event handlers need an EventHandlers.xml uploaded to MDS; similarly, scheduled tasks need to be defined in a task.xml file.
It is also worth nothing that OIM 9.x also had a concept of "event handler", but the technology was different from that in OIM 11g. OIM 9.x event handlers extend class com.thortech.xl.client.events.tcBaseEvent. As a general rule, 9.x event handlers are no longer supported in 11g.
For more information, read these chapters in the OIM 11.1.2.3 Developer Guide: chapter 17 for basics of plugin development, chapter 18 for developing custom event handlers, and chapter 16 for developing custom scheduled tasks, and appendix B for developing custom username and common name generation/validation policies.
Also, if you want some samples, and have access to My Oracle Support, check out these documents:
OIM11g: Sample Code For A Custom Username Generation Policy Plugin Using JDeveloper (Doc ID 1228035.1)
OIM11g: Sample Code For A Custom Event Handler Implemented for Pre-Process Stage During Create User Management Operation (Doc ID 1262803.1)
How To Create A Request Validator To Validate Justification Attribute in OIM 11g (Doc ID 1317087.1)
How To Determine OIM User Attribute Changes In A Modify Orchestration (Doc ID 1535503.1)
A plugin is a module of code which can be run inside the OIM server. It contains Java classes which are executed along with metadata (
plugin.xml
) which identifies them. There are many types of plugins - the type is determined by the Java interface or abstract class the plugin implements/extends.One of the core components of OIM is the orchestration engine. It processes create/update/delete transactions on core identity objects (e.g. User, Role, etc). Each orchestration process involves the execution of a sequence of event handlers, and each event handler is a plugin implementing
oracle.iam.platform.kernel.spi.EventHandler
. Many are shipped out-of-the-box, and you can write custom ones too. For example, you could install an event handler to run after (postprocess) the creation of any user.However, there are also other types of plugins - for example, login name generation plugins (
oracle.iam.identity.usermgmt.api.UserNamePolicy
). Some of these plugins are actually called by the out-of-the-box event handlers. Event handlers are a very general API (they are similar in concept to database triggers) - they have a lot of power, but if you are not careful with that power you can destabilise your OIM environment. By contrast, other plugin interfaces perform one specific task only (such as generating a login name for a new user), and thus the risk from using them is much less. If you can solve your problem using some more specific type of plugin, do that in preference to using an event handler.You will also find, that while some of these more specific plugin interfaces are called by out-of-the-box event handlers, others are not called by the orchestration engine at all, but instead by other components in OIM. For example, scheduled tasks are not run by the orchestration engine, but instead by the embedded Quartz scheduler. Custom scheduled tasks extend the
oracle.iam.scheduler.vo.TaskSupport
abstract class.While every plugin needs the plugin framework metadata (
plugin.xml
), some specific types of plugins need additional metadata specific to that type. For example, event handlers need anEventHandlers.xml
uploaded to MDS; similarly, scheduled tasks need to be defined in atask.xml
file.It is also worth nothing that OIM 9.x also had a concept of "event handler", but the technology was different from that in OIM 11g. OIM 9.x event handlers extend class
com.thortech.xl.client.events.tcBaseEvent
. As a general rule, 9.x event handlers are no longer supported in 11g.For more information, read these chapters in the OIM 11.1.2.3 Developer Guide: chapter 17 for basics of plugin development, chapter 18 for developing custom event handlers, and chapter 16 for developing custom scheduled tasks, and appendix B for developing custom username and common name generation/validation policies.
Also, if you want some samples, and have access to My Oracle Support, check out these documents: