Virtual member manager is configured to use the dynamic
model. You can create new property types and add them to existing
virtual member manager built-in entity types dynamically at runtime.
About this task
You need to call the virtual member manager createSchema
API to create new property types and add them to existing virtual
member manager built-in entity types at runtime without restarting
virtual member manager. Out-of-the-box, both the LDAP Adapter and
the DB Adapter supports this type of procedure. For this example you
want to create a new property type called postOfficeBox and add this
property type to the virtual member manager built-in entity type
PersonAccount. This example uses the LDAP Adapter.
Perform the
following:
Procedure
- If the underlying adapters include LDAP Adapter, ensure
that the corresponding LDAP attribute schema of the new property type
is defined on LDAP server and contained by the LDAP object classes
of entity type. Virtual member manager does not provide
function to create and update LDAP schema on LDAP server. In this
example, the object class inetOrgPerson of entity type PersonAccount
already contains LDAP attribute postOfficeBox
If underlying adapters
include DB Adapter, no extra preparation is needed.
- On the client side, construct a data graph to create the
new property type. The data object PropertySchema is used for creating a new property
type. Attributes like propertyName, dataType, multiValued are used
for specifying the metadata of the new property type. The applicable
entity types are defined in the element applicableEntityTypeNames.
Multiple entity types can be specified. You can define the corresponding
repository attribute name of this property by adding an LDAP attribute
configuration and specifying the name of the corresponding virtual
member manager property name. For information on configuring this
using command-line interface, read about the addIdMgrLDAPAttr command
in IdMgrRepositoryConfig command group for the AdminTask
object, in the WebSphere Application Server information center.
Note: If
you also want to extend the database schema of the property extension
repository, you must use the extensionPropertySchema data object.
This will add the new property to the existing entity type and store
the property in the property extension database. The property extension
repository must be configured before you can use extensionPropertySchema.
For more information, read about
Configuring a property extension repository in a
federated repository configuration in the WebSphere Application
Server information center.
The following
is the sample data graph. The new property type to be created is called
postOfficeBox and is added to entity type PersonAccount. Because the
corresponding LDAP attribute name postOfficeBox is same as the property
name, you do not need to add an LDAP configuration for this property
name.
<?xml version="1.0" encoding="UTF-8"?>
<sdo:datagraph xmlns:sdo="commonj.sdo"
xmlns:wim="http://www.ibm.com/websphere/wim">
<wim:schema>
<wim:propertySchema nsURI="http://www.yourco.com/wim/yourext"
dataType="STRING" multiValued="true"
propertyName="postOfficeBox">
<wim:applicableEntityTypeNames>PersonAccount</wim:applicableEntityTypeNames>
</wim:propertySchema>
</wim:schema>
</sdo:datagraph>
Results
On the client side, the exploiting virtual member manager
application calls the virtual member manager createSchema API through
the Local Service Provider. Local Service Provider detects that this
call changes the schema and updates the local schema (ECore) after
the createSchema API call is finished.
On the server side, the
Schema Manager receives the API call from client. The Schema Manager
first checks if the new property types already exist and throws an
exception if they do. Then the Schema Manager updates the ECore model
in memory to add new entity types to existing entity types. In this
sample, the EClass of PersonAccount is added a new EAttribute called
postOfficeBox.
The Schema Manager adds the schema of the new
property types to the wimxmlextension.xml file. The following is
the sample content of the wimxmlextension.xml file after this update
is finished.
<wim:propertySchema nsURI="http://www.yourco.com/wim/yourext"
dataType="STRING" multiValued="true" propertyName="postOfficeBox">
<wim:applicableEntityTypeNames>PersonAccount</wim:applicableEntityTypeNames>
</wim:propertySchema>
The Schema Manager calls the Repository Manager which
in turn calls the createSchema SPI method of all the adapters.
Adapters
that support creating schema then perform any necessary operations
to support the new schema. As examples, the LDAP Adapter refreshes
the cache to reflect the changes in schema and configuration. The
DB Adapter creates the schema of the new entity and property in its
database and refreshes its caches.
Note: Adapters that do not support
creating schema, for example the File Adapter which does not support
creating new types at runtime, throw an OperationNotSupportedException.
If
at least one repository adapter supports creating new entities and
does not throw the OperationNotSupportedException, virtual member
manager returns the repository IDs of these repositories in the output
data graph.
At client side, after the createSchema API call
is returned, the Local Service Provider calls the getEPackages API
to retrieve the latest schemas. The Local Service Provider reregisters
the schemas in the client JVM. Exploiting applications can call the
virtual member manager create API to create a new entity of type PersonAccount
with property postOfficeBox. Virtual member manager does not need
to restart for the schema change to become active.