Express (Distributed operating systems), v8.0 > Secure applications and their environment > Authenticate users > Select a registry or repository > Manage realms in a federated repository > Virtual member manager > Develop with virtual member manager > Extend virtual member manager functionality in the application > Dynamic model schema loading process
Dynamic model: adding new properties to virtual member manager entities at runtime
Virtual member manager is configured to use the dynamic model. We 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. We 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 , in the WAS information center.
For more information about using the propertySchema and extensionPropertySchema data objects, see the section, Extend property schema in the topic, Program prerequisites. Also read about Configure a property extension repository in a federated repository 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="//www.ibm.com/websphere/wim"> <wim:schema> <wim:propertySchema nsURI="//publib.boulder.ibm.com/infocenter/wasinfo/v8r0/index.jsp?topic=/ ://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="//publib.boulder.ibm.com/infocenter/wasinfo/v8r0/index.jsp?topic=/ ://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.
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.
Example
For sample data graphs and code, see Create a new property type and adding it to an existing entity type.
Parent topic: Dynamic model schema loading process