After finishing the preparation work described in Preparing for Adapter Development you are ready to start writing your custom adapter.
This section describes how to write a custom adapter, including:
The following sections provide a high-level overview of the steps you perform to create a custom adapter:
This section describes the processes to follow when creating a standard adapter or an Active Sync-enabled adapter.
The steps for writing a standard adapter are slightly different based on which operating system you are using.
Open a command window and go to the following directory:
\waveset\idm\adapter\src
Rename the SkeletonStandardResourceAdapter.java skeleton file to a file name of your choice. See Rename the Skeleton File for more information.
Edit the new adapter’s source file as described in Edit the Source File.
Source the file you created previously to set up your environment:
For Windows: Source the ws.bat file.
For UNIX: Source the ws.sh file.
Type the following command to compile your source files:
For Windows: javac -d . -classpath %CLASSPATH% yourfile.java
For UNIX: javac -d . -classpath $CLASSPATH yourfile.java
This section describes the general steps you follow to create a custom Active Sync-Enabled adapter on the Microsoft Windows operating system.
Open a command window and change to the following directory:
\waveset\idm\adapter\src
Rename (or copy) one of the following skeleton files to a file name of your choice. See Rename the Skeleton File for more information.
SkeletonStandardAndActiveSyncResourceAdapter.java (for standard and Active Sync-enabled resources)
SkeletonActiveSyncResourceAdapter.java (for Active Sync-only resources)
Edit the new adapter’s source file as described in Edit the Source File.
Source the file you created previously to set up your environment:
For Windows: Source the ws.bat file.
For UNIX: Source the ws.sh file.
Type the following command to compile your source files:
For Windows: javac -d . -classpath %CLASSPATH% yourfile.java
For UNIX: javac -d . -classpath $CLASSPATH yourfile.java
You must rename the skeleton adapter to a name that is appropriate for your new adapter. Perform the following actions:
Rename the sample java file to match your new class name.
Edit the source code to replace the sample class name with the new class name.
After renaming the skeleton file, you must edit the new adapter’s source code to replace specific text strings and to define default values you want the adapter to support.
Search for, and replace, the following text strings to determine where you must make adapter-specific modifications in the code.
Name the resource adapter type.
This name displays in the New Resources menu in the Waveset Administrator interface.
Map the incoming resource attributes to Waveset account attributes by replacing default values in the prototypeXML string with your own default values for this adapter type. For example, you might want to delete the RA_GROUPS attribute from your adapter type.
See Map the Attributes for more information.
Add or delete methods from the skeleton file. In particular, you must add Java code to support join, leave, and move operations, which are not supported in this example file.
See Write the Adapter Methods for more information.
After editing the adapter file, you can load it into Waveset.
Generally, you set options for the adapter type by mapping the incoming resource attributes to the standard Waveset account attributes or by creating your own custom attributes (called extended schema attributes).
Your resource must define resource attributes and set default values for resource attributes for which it makes sense to have default. The resource does not have to present the prototypeXML object.
The attributes in SkeletonActiveSyncResourceAdapter are mandatory. Do not delete these attribute definitions when customizing the file.
To map incoming resource attributes to one of the standard Waveset account attributes, use the syntax shown in the following example.
Where:
The <AccountAttributesTypes> element surrounds the prototypeXML string where you map the resource attribute to the Waveset account attribute.
The <AttributeDefinitionRef> element identifies the Waveset account attribute.
The following table describes the <AttributeDefinitionRef> element fields.
Element Field |
Description |
---|---|
name |
Identifies the Waveset account attribute to which the resource attribute is being mapped. (The left column on the resource schema page in the Waveset User Interface.) |
mapName |
Identifies the name of the incoming resource attribute. When editing the skeleton file, replace change-value-here with the resource attribute name. |
mapType |
Identifies the incoming attribute type, which can be string, int, or encrypted. |
For more information on mapping resource attributes to account attributes, see Map the Attributes.
To map incoming resource attributes to attributes other than a standard Waveset attribute, you must create an extended schema attribute. The following example illustrates how to map a resource attribute to an extended schema attribute.
<AccountAttributeType name=’HomeDirectory’ type=’string’ mapName=’HomeDirectory’ mapType=’string’>\n"+ </AccountAttributeType>\n"+ |
You do not have to declare an ObjectRef type. The mapName field identifies the custom account attribute HomeDirectory. You define the mapType field the same as you would when mapping an attribute to a standard account attribute.
You must use an identity template (or an account DN) to uniquely identify every user and group in your enterprise.
DNs display on the following Waveset User interface pages:
Resources
Distinguished Name Template
Edit Schema
For more information about identity templates, see Identity Template.
The Waveset adapter interface provides general methods that you must customize to suit your particular environment. This section briefly describes:
Standard resource adapter-specific methods are specific to the resource you are updating to synchronize with Waveset.
The body of a resource adapter consists of resource-specific methods. Consequently, the resource adapter provides methods that are only generic placeholders for the specific methods that you will write.
This section describes how the methods used to implement operations are categorized. The information is organized into the following sections:
When writing a custom adapter
Call the setdisabled() method on any WSUser object that is returned by a custom method.
If the adapter implements the AsynchronousResourceAdapter class, then note that this adapter might be working with users that are partially initialized. (These users are created outside Waveset, but not fully populated with attributes.) The Provisioner does not automatically convert a Create operation to an Update operation if the WSUser already exists on the resource. Your resource adapter must distinguish this case.
The following table describes the methods used to create a Resource instance.
Table 10–14 Methods Used to Create a Resource Instance
The following methods are responsible for establishing connections and disconnections as an authorized user. All resource adapters must implement these methods.
ResourceAdapterBase provides methods that you can use to check the validity of an operation, such as whether the connection to the resource is working, before the adapter attempts the actual operation.
The following table describes methods you can use to verify that your adapter is communicating with the resource and that the authorized account has access.
Table 10–15 Methods Used to Check Communication
The getFeatures() method specifies which features are supported by an adapter. The features can be categorized as follows:
General features
Account features
Group features
Organizational unit features
The ResourceAdapterBase class defines a base implementation of the getFeatures() method. The Enabled in Base? column in the following tables indicates whether the feature is defined as enabled in the base implementation in ResourceAdapterBase.
Table 10–16 General Features
Feature Name |
Enabled in Base? |
Comments |
---|---|---|
ACTIONS |
No |
Indicates whether before and after actions are supported. To enable, override the supportsActions method with a true value. |
RESOURCE_PASSWORD_CHANGE |
No |
Indicates whether the resource adapter supports password changes. To enable, override the supportsResourceAccount method. |
Table 10–17 Account Features
Table 10–18 Group Features
Feature Name |
Enabled in Base? |
Comments |
---|---|---|
GROUP_CREATE,GROUP_DELETE, GROUP_UPDATE |
No |
Indicates whether groups can be created, deleted, or updated. Use the put operation to if these features are supported on the resource. |
Table 10–19 Organizational Unit Features
Feature Name |
Enabled in Base? |
Comments |
---|---|---|
ORGUNIT_CREATEORGUNIT_DELETEORGUNIT_UPDATE |
No |
Indicates whether organizational units can be created, deleted, or updated. Use the put operation to if these features are supported on the resource. |
If your custom adapter overrides the ResourceAdapterBase implementation of the getFeatures method, add code similar to the following:
public GenericObject getFeatures() { GenericObject genObj = super.getFeatures(); genObj.put(Features.ACCOUNT_RENAME, Features.ACCOUNT_RENAME); genObj.remove(Features.ACCOUNT_UPDATE, Features.ACCOUNT_UPDATE); .. other features supported by this Resource Adapter … return genObj; } |
To disable a feature by overriding a different method (such as supportsActions) add code similar to the following:
public boolean supportsActions() { return true; } |
The following tables describe the methods used to create, delete, and update accounts on Resources.
Table 10–20 Creating Accounts on the Resource
Method |
Description |
---|---|
realCreate() |
Creates the account on the resource. Receives a user object as input, and contains the account attribute information needed to create the user account (such as account name, password, and user name) |
Table 10–21 Deleting Accounts on the Resource
Method |
Description |
---|---|
realDelete() |
Deletes one or more accounts on the resource. Receives a user object or list of user objects as input. By default, this method creates a connection, calls realDelete, closes the connection for each user object in the list. |
Table 10–22 Updating Accounts on the Resource
Method |
Description |
---|---|
realUpdate() |
Updates a subset of the account attributes. By default, this method creates a connection, calls realUpdate, and closes the connection for each user object in the list. NOTE: User account attributes from the resource are merged with any new changes from Waveset. |
Table 10–23 Getting User Information
Method |
Description |
---|---|
getUser() |
Retrieves information from the resource about user attributes. Receives a user object as input (typically with only an account identity set), and returns a new user object with values set for any attribute defined in resource schema map. |
You can use list methods to establish processes that adapters use to retrieve user information from the resource.
Table 10–24 List Methods
Method |
Description |
---|---|
getAccountIterator() |
Used to discover or import all the users from a resource. Implements the Account Iterator interface to iterate over all users of a resource. |
listAllObjects () |
Given a resource object type (such as accountID or group), returns a list of that type from the resource. Implement this method to generate lists that are used by the resource, such as a list of resource groups or distribution lists. This method is called from the user form (not called by provisioning engine). |
Best Practice
When writing an AccountIterator interface implementation for a custom adapter, try to do the following:
Have the AccountIterator.next() method return a user that contains all attributes in the schema map when getAccountIterator() is called. The reconciler will trim the schema (in a cloned resource used for the getAccountIterator() request) to request only those attributes the reconciler needs. Generally, the reconciler needs only the accountId attribute; but there are cases when the reconciler has additional attributes in the schema. Other getAccountIterator() users, such as Load From Resource, potentially need all of the schema attributes.
Try to create a “smart” adapter that does the right thing based on what is in the schema map. If your adapter can just list the accounts and get the requested information, then the adapter should just do those tasks. Otherwise, the adapter might have to fetch an account to get the required attributes. Adapters that are not smart always get all the attributes.
Make your adapter as scalable as possible, which generally means the adapter does not list or fetch all of the accounts at once. Instead, your adapter should iterate over the accounts as the AccountIterator.next() method is called. Avoid having your adapter do much in the AccountIterator constructor.
The following example shows code for retrieving information from a resource and converting that information into information that Waveset can work with.
Resource Adapters: Retrieving Information on a Resource
public WSUser getUser(WSUser user) throws WavesetException { String identity = getIdentity(user); WSUser newUser = null; try { startConnection(); Map attributes = fetchUser(user); if (attributes != null) { newUser = makeWavesetUser(attributes); } } finally { stopConnection(); } return newUser; } |
Method |
Description |
---|---|
supportsAccountDisable() |
Returns true or false depending on whether the resource supports native account disable. |
realEnable() |
Implements native calls that are needed to enable the user account on the resource. |
realDisable() |
Implements native calls that are needed to disable the user account on the resource. |
You can disable an account by using the disable utilities supported by the resource or the account disable utility provided by Waveset.
Use native disable utilities whenever possible.
Native support for disabling an account: Certain resources provide a separate flag that, when set, prevents users from logging in. Example utilities include User Manager for Active Directory Users and Computers for Active Directory, and ConsoleOne or Netware Administrator for NDS/Netware. When an account is enabled, the user’s original password is still valid. You can determine whether native support for account disable is available on your resource by implementing the supportsAccountDisable method.
Waveset disable utility: If the resource does not support disabling an account, or supports disable by means of resetting the user’s password, the Waveset provisioning engine disables the account. You can perform the disable by setting the user account to a randomly generated, non-displayed, non-retained password. When the account is enabled, the system randomly generates a new password, which is displayed in the Waveset Administrative interface or emailed to the user.
Use the following general steps to enable pass-through authentication in a resource type:
Ensure that the adapter’s getFeatures() method returns ResourceAdapter.ACCOUNT_LOGIN as a supported feature.
If your custom adapter overrides the ResourceAdapterBase implementation, add the following code.
public GenericObject getFeatures() { GenericObject genObj = super.getFeatures(); genObj.put(Features.ACCOUNT_RENAME, Features.ACCOUNT_RENAME); .. other features supported by this Resource Adapter … return genObj; } |
If your custom adapter does not override the getFeatures() implementation in the ResourceAdapterBase class, it will inherit the getFeatures() implementation that is exported for ACCOUNT_LOGIN by default.
Add the <LoginConfigEntry> element to the adapter’s prototypeXML.
Implement the adapter’s authenticate() method.
The authenticate() method authenticates the user against the resource by using the authentication property name/value pairs provided in the loginInfo map. If authentication succeeds, be sure that the authenticated unique ID is returned in the WavesetResult by adding a result as follows:
result.addResult(Constants.AUTHENTICATED_IDENTITY, accountID); |
If authentication succeeded, but the user’s password was expired, then in addition to the identity added above, also add the password expired indicator to the result to be returned. This will ensure that the user will be forced to change their password on at least resource upon next login to Waveset.
result.addResult(Constants.RESOURCE_PASSWORD_EXPIRED, new Boolean(true)); |
If authentication fails (because the user name or password is invalid), then:
throw new WavesetException("Authentication failed for " + uid + "."); |
Active Sync-specific methods provide the mechanism for updating Waveset, which is the primary purpose of your Active Sync-enabled adapter adapter. These methods are based on pulling information from the authoritative resource. In addition, you use these methods to start, stop, and schedule the adapter.
The methods you are going to write in this section of the adapter are based on generic methods supplied with the skeleton adapter file. You must edit some of these methods, which are categorized by task.
The following sections describe general guidelines for creating Active Sync-enabled adapter methods:
You initialize and schedule the adapter by implementing the init() and poll() methods.
The init() method is called when the adapter manager loads the adapter. There are two methods for loading the adapter:
The manager can load the adapter at system startup if the adapter startup type is automatic.
An administrator loads the adapter by clicking Start on the Resources page if the adapter startup type is manual.
In the initialization process, the adapter can perform its own initialization. Typically, this involves initializing logging (with the ActiveSyncUtil class), and any adapter-specific initialization such as registering with a resource to receive update events.
If an exception is thrown, the adapter is shut down and unloaded.
All of the adapter’s work is performed by the poll() method. Scheduling the adapter requires setting up a poll() method to search for and retrieve changed information on the resource.
This method is the main method of the Active Sync-enabled adapter. The adapter manager calls the poll() method to poll the remote resource for changes. The call then converts the changes into IAPI calls and posts them back to a server. This method is called on its own thread and can block for as long as needed.
It should call its ActiveSyncUtil instance’s isStopRequested method and return when true. Check isStopRequested as part of the loop condition when looping through changes.
To configure defaults for polling, you can set the polling-related resource attributes in the adapter file. Setting these polling-related attributes provides administrators with a means to later use the Waveset interface to set the start time and date for the poll interval and the length of the interval.
Scheduling Parameters
You use the following scheduling parameters in Active Sync-enabled adapters:
RA_SCHEDULE_INTERVAL
RA_SCHEDULE_INTERVAL_COUNT
RA_SCHEDULE_START_TIME
RA_SCHEDULE_START_DATE
See Table 10–6 for a description of these parameters.
Scheduling Parameters in the prototypeXML
The scheduling parameters are present in the string constant ActiveSync. ACTIVE_SYNC_STD_RES_ATTRS_XML, along with all other general Active Sync-related resource attributes.
The following table describes the usage of scheduling parameters using some sample polling scenarios.
Table 10–26 Sample Polling Scenarios
Polling Scenario |
Parameters |
---|---|
Daily at 2 A.M. |
Interval = day, count =1, start_time=0200 |
Four times daily |
Interval=hour, count=6. |
Poll once every two weeks on Thursday at 5 P.M |
Interval = week, count=2, start date = 20020705 (a Thursday), time = 17:00. |
Most Active Sync-enabled adapters are also standard adapters, where a single Java class both extends ResourceAdapterBase (or AgentResourceAdapter) and implements the Active Sync interface.
The following example shows how to retrieve the attribute and pass the update through to the base.
public Object getAttributeValue(String name) throws WavesetException { return getResource().getResourceAttributeVal(name); } public void setAttributeValue(String name, Object value) throws WavesetException { getResource().setResourceAttributeVal(name,value); |
When an update is received, the adapter uses the IAPI classes, notably IAPIFactory to:
Collect the changed attributes
Map the changes to a unique Waveset object
Update that object with the changed information
Using the Active Sync event parameter configurator for the resource, IAPIFactory.getIAPI constructs an IAPI object, either IAPIUser or IAPIProcess from a map of changed attributes. If an exclusion rule (iapi_create, iapi_delete, or iapi_update) is configured for the resource, IAPIFactory checks if the account is excluded. If a non-null object is created and returned by the Factory, the adapter can modify the IAPI object (for example, by adding a logger), then submits it.
When the object is submitted, the form associated with the resource is expanded with the object view before the view is checked in. For more information about forms and views, see Deployment Reference.
In SkeletonActiveSyncResourceAdapter, this process is handled in the buildEvent and processUpdates methods.
No system requirements are associated with adapter shutdown. Waveset calls the shutdown method, which is an opportunity for your adapter to cleanup any objects still in use from the polling loop.
Waveset uses pass-through authentication to grant users and administrators access through one or more different passwords. Waveset manages pass-through authentication through the implementation of:
Login applications (collection of login module groups)
Login module groups (ordered set of login modules)
Login modules (sets authentication for each assigned resource and specify one of several success requirements for authentication)
You configure a custom adapter to support pass-through authentication by
Implementing the authenticate() method appropriately
Including the account.LOGIN feature in the getFeatures() method map (com.waveset.adapter.ResourceAdapter.ACCOUNT_LOGIN)
Including the <LoginConfigEntry> section in the resource’s prototypeXML
When configuring a custom resource adapter to support an interactive login, you must enable the adapter to request additional information from a user during log in and after that user submits the initial login page.
The adapter authenticate() method controls whether the login becomes interactive. The authenticate() method’s return values trigger the interactive login so the authenticate() is called again with the results of the next login page until the authenticate() method decides the login
Fails by throwing an exception
Succeeds by returning the account ID of the authenticated account in the WavesetResult as usual
To be interactive, the adapter must return a WavesetResult that
Does not contain ResultItems with a Constants.AUTHENTICATED_GUID type or Constants.AUTHENTICATED_IDENTITY type
Does contain ResultItems that are used to dynamically build a form for the next page of the login
Each ResultItem corresponds to a field in the form. ResultItems must have the Constants.CONTINUE_AUTHENTICATION_ATTR type with values in the following format:
label|attrName|displayType|prompt|’isId’
Where
label is a string containing a label or none.
attrName is the login attribute name that is passed into the next authenticate() method call as a key in the loginInfo HashMap.
displayType describes the type of form field to use. displayType values include
text
secret
label
checkbox
prompt corresponds to the title or label of the form field.
isId is an optional string.
If you use the isId string, the value of the form field is added to the loginInfo HashMap with the key Constants.ACCOUNT_ID and the value of the field.
The following ResultItem types are also “round-tripped” and returned in the loginInfo HashMap on the next authenticate() call:
Constants.CONTINUE_AUTHENTICATION_ACCOUNT_HANDLE keep track of which user or account is in the process of being authenticated.
Constants.CONTINUE_AUTHENTICATION_PREVIOUS_ATTR remove previous authentication attributes from the loginInfo, so the loginInfo does not contain an “old” authentication attr.
This section describes how to define the following resource object components:
Object classes are handled differently for LDAP-based resource objects than for other resource objects.
LDAP-based resource objects can consist of more than one LDAP object class, where each object class is an extension of its parent object class. However, within LDAP, the complete set of these object classes is viewed and managed as a single object type within LDAP.
To manage this type of resource object within Waveset, include the XML element <ObjectClasses> within the <ObjectType> definition. The <ObjectClasses> element allows you to define the set of object classes that is associated with this <ObjectType> as well as the relationship of classes to each other.
For non-LDAP-based resource objects, you can use the <ObjectType> to represent information other than the resource object type name.
In the following example, the primary attribute defines the object class to be used when creating and updating an object of this type. In this case, inetorgperson is the object class that is defined as the primary one because it is a subclass of the other listed object classes. The operator attribute specifies whether the list of object classes should be treated as one (logical AND) or treated as unique classes (logical OR) when listing or getting an object of this type. In this case, Waveset performs an AND operation on these object classes prior to any list or get requests for this object type.
<ObjectClasses primary=’inetorgperson’ operator=’AND’>\n"+ <ObjectClass name=’person’/>\n"+ <ObjectClass name=’organizationalPerson’/>\n"+ <ObjectClass name=’inetorgperson’/>\n"+ </ObjectClasses>\n"+ |
In the next example, all requests to create and/or update resource objects of this type are done using the groupOfUniqueNames object class. All list and get requests will query for all objects whose object class is either groupOfNames or groupOfUniqueNames.
<ObjectClasses primary=’groupOfUniqueNames’ operator=’OR’>\n"+ <ObjectClass name=’groupOfNames’/>\n"+ <ObjectClass name=’groupOfUniqueNames’/>\n"+ </ObjectClasses>\n"+ |
In this example, only one object class is defined so all create, get, list, and update operations are performed using object class organizationalUnit.
<ObjectClasses operator=’AND’>\n"+ <ObjectClass name=’organizationalUnit’/>\n"+ </ObjectClasses>\n"+ |
Because there is only one object class, you can exclude the <ObjectClasses> section. If you exclude the <ObjectClasses> section, the object class defaults to the <ObjectType> name attribute value. However, if you want the object type name to differ from the resource object class name, you must include the <ObjectClasses> section with the single <ObjectClass> entry.
Resource Object types uniquely define a specific type of resource, and you define object types in the adapter’s prototypeXML string.
The XML <ObjectTypes> element is a container within the adapter’s prototypeXML string that contains one or more object type definitions to be managed on that resource. This <ObjectTypes> element fully describes the resource-specific object to Waveset, including the following:
A list of specific object classes contained in the object type (required only for LDAP-compliant directories)
A list of supported features
A list of object type-specific attributes that are available within Waveset for editing and searching
The following table describes the supported attributes of the <ObjectType> element.
Table 10–27 Supported <ObjectType> Element Attributes
The following example shows ObjectType definitions:
static final String prototypeXml = "<Resource name=’Skeleton’ class= ’com.waveset.adapter.sample.SkeletonStandardResourceAdapter’ typeString=’Skeleton of a resource adapter’ typeDisplayString=’"+Messages.RESTYPE_SKELETON+"’>\n"+ " <ObjectTypes>\n"+ " <ObjectType name=’Group’ icon=’group’>\n"+ … other content defined below will go here … " </ObjectType>\n"+ " <ObjectType name=’Role’ icon=’ldap_role’>\n"+ … other content defined below will go here … " </ObjectType>\n"+ " <ObjectType name=’Organization’ icon=’folder_with_org’ container=’true’>\n"+ … other content defined below will go here … "</ObjectType>\n"+ " </ObjectTypes>\n”+ |
The <ObjectFeatures> section specifies a list of one or more features supported by this object type, where each object feature is directly tied to the implementation of the associated object type method in the resource adapter.
Each ObjectFeature definition must contain the name attribute, which specifies a feature name. The create and update features can specify a form attribute, which defines the resource form used to process create and update features. If you do not specify a form attribute, Waveset processes the create and update features with the same form used by all resources of a given type.
The following table describes the object feature mappings.
Table 10–28 Object Feature Mappings
Object Feature |
Method |
Supports Form Attribute? |
---|---|---|
create |
createObject |
Yes |
delete |
deleteObject |
No |
find |
listObjects |
No |
list |
listObjects |
No |
rename |
updateObject |
No |
saveas |
createObject |
No |
update |
updateObject |
Yes |
view |
getObject |
No |
In the following example, the <ObjectFeatures> section includes all supported object features. Your resource adapter can support all of these features or just a subset of features. The more object features your adapter supports, the richer the object management function within Waveset.
<ObjectFeatures>\n"+ <ObjectFeature name=’create’ form=’My Create Position Form’/> <ObjectFeature name=’update’ form=’My Update Position Form’/> <ObjectFeature name=’create’/>\n"+ <ObjectFeature name=’delete’/>\n"+ <ObjectFeature name=’rename’/>\n"+ <ObjectFeature name=’saveas’/>\n"+ <ObjectFeature name=’find’/>\n"+ <ObjectFeature name=’list’/>\n"+ <ObjectFeature name=’view’/>\n"+ </ObjectFeatures>\n"+ |
The <ObjectAttributes> section specifies the set of attributes to be managed and queried in Waveset. Each <ObjectAttribute> element name should be the same as the native resource attribute name. Unlike user attributes in Waveset, no attribute mapping is specified. Use only the native attribute names.
The following table describes attributes that are required for <ObjectAttributes>.
Table 10–29 Required Attributes for <ObjectAttributes>
Attribute |
Description |
---|---|
idAttr |
The value of this attribute should be the resource object attribute name that uniquely identifies this object within the resource’s object namespace (for example, dn, uid) |
displayNameAttr |
The value of this attribute should be the resource object attribute name whose value is the name you want displayed when objects of this type are viewed within Waveset (for example, cn, samAccountName). |
descriptionAttr |
(Optional) This value of this attribute should be the resource object attribute name whose value you want displayed in the Description column of the Resources page. |
The following example shows an <ObjectAttributes> section defined in an <ObjectType>.
<ObjectAttributes idAttr=’dn’ displayNameAttr=’cn’ descriptionAttr= ’description’>\n"+ <ObjectAttribute name=’cn’ type=’string’/>\n"+ <ObjectAttribute name=’description’ type=’string’/>\n"+ <ObjectAttribute name=’owner’ type=’distinguishedname’ namingAttr=’cn’/>\n"+ <ObjectAttribute name=’uniqueMember’ type=’dn’ namingAttr=’cn’ />\n"+ </ObjectAttributes>\n"+ |
The following table describes the <ObjectAttribute> attributes.
Table 10–30 <ObjectAttribute> Attributes
Attribute |
Description |
---|---|
name |
Identifies the resource object type attribute name (required) |
type |
Identifies the type of object. Valid types include string or distinguishedname / ”dn’ (defaults to string) |
namingAttr |
If object type is distinguishedname or dn, this value specifies the attribute whose value should be used to display an instance of this object type referred to by the dn within Waveset |
The methods in the resource adapter object type implementation are responsible for coercing all string values into the appropriate type based on the resource attribute name.
You must provide the following resource forms:
A ResourceForm named <resource type> Create <object type> Form for each resource <ObjectType> that supports the Create feature.
For example, AIX Create Group Form or LDAP Create Organizational Unit Form
A ResourceForm named <resource type> Update <object type> Form for each resource <ObjectType> that supports the Update feature.
For example, AIX Update Group Form or LDAP Update Organizational Unit Form
You can also assign an optional form that processes incoming data before storing it in Waveset. This resource form is a mechanism that transforms incoming data from the schema map and applies the transformed data to the User view. The sample form also performs actions, such as enabling and disabling an account, that are based on specific incoming data values such as employee status.
The following table describes attributes contained in the top-level namespace.
All values are strings unless otherwise specified.
Attribute |
Description |
---|---|
<objectType>.resourceType |
Waveset resource type name (for example, LDAP, Active Directory) |
<objectType>.resourceName |
Waveset resource name |
<objectType>.resourceId |
Waveset resource ID |
<objectType>.objectType |
Resource-specific object type (for example, Group) |
<objectType>.objectName |
Name of resource object (for example, cn or samAccountName) |
<objectType>.objectId |
Fully qualified name of resource object (for example, dn) |
<objectType>.requestor |
ID of user requesting view |
<objectType>.attributes |
Resource object attribute name/value pairs (object) |
<objectType>.organization |
Waveset member organization |
<objectType>.attrsToGet |
List of object type specific attributes to return when requesting an object through checkoutView or getView (list) |
<objectType>.searchContex |
Context used to search for non-fully qualified names in form input |
<objectType>.searchAttributes |
List of resource object type-specific attribute names that will be used to search within the specified searchContext for names input to the form (list). |
<objectType>.searchTimeLimit |
Maximum time spent searching where <objectType> is the lowercase name of a resource specific object type. For example, group, organizationalunit, organization. |
<objectType>.attributes<resource attribute name> |
Used to get or set the value of specified resource attribute (for example, <objectType>.attributes.cn, where cn is the resource attribute name). When resource attributes are distinguished names, the name returned when getting the value is the value of the namingAttr specified in the <ObjectAttribute> section of the <ObjectType> description. |