Implementing the modify operation involves extending AbstractAttributeStyleProcessor (or a class deriving from it) and implementing the following method:
implementing AttributeStyle
public void doModify(ObjectInfo objInfo, ModificationItem[] items) throws NamingException
Note: For more information, see com/ca/jcs/processor/OpProcessor.html#doModify(com.ca.jcs.ObjectInfo,%20javax.naming.directory.ModificationItem[]) in the CA IAM CS Javadoc in the CA IdentityMinder bookshelf, and the SDK Sample connector for a complete sample implementation.
And for method-style involves implementing:
Implementing OpBindingsProcessor
void doUpdate(OpBindingType opBinding, ObjectInfo info, Map parameterValues) throws NamingException;
Note: See the add operation for descriptions of the missing parameters. For further information about these parameters, see the CA IAM CS Javadoc in the CA IdentityMinder bookshelf.
Contains the list of attributes that are modified. getModificationOp() can be used to indicate what operation is performed (like ADD, REPLACE, or REMOVE) and getAttribute() provides the attribute details.
Update the endpoint system to record the object's modification, given a reference to it (objInfo) and an array of modification items.
If multiple object types can be modified, you can distinguish which type is being requested by examining objInfo.getObjectClassMapping().getConnectorClassName(), which yields the connectorMapTo defined in the metadata for this object.
The CA IAM CS framework runs any required validators or converters before you invoke this method.
The forceModificationMode metadata setting can significantly simplify coding of modification logic for multivalued attributes in many cases. The setting normalizes all modifications to either of the following, according to the requirements of the endpoint system with which your connector interacts:
For example, the SDK example connector uses this metadata setting on the eTSDKAccount.eTSDKGroupMembers attribute so that it is always handed the new set of values to persist, regardless of whether the original modification mode was ADD, REMOVE, or REPLACE. As a consequence, its code is simplified considerably.
Note: See the CA IAM CS Javadoc in the CA IdentityMinder bookshelf for information about the MetaDataDefs.MD_FORCE_MOD_MODE constant.
Modify the provided attributes on the endpoint system. For example, a JDBC connector would translate this list into the column name and values of an update statement. An endpoint called by a Java API would translate these into the appropriate endpoint objects to represent a rename.
As the modification attributes are provided in an array for modification, rather than the List of attributes supplied when adding a new entry, the code snippet for splitting the associations from ordinary attributes changes slightly.
SplitModificationItems splitItems = objInfo.getObjectClassMapping().splitAssocModificationItems(items); if (splitItems != null) items = splitItems.nonAssocItems; if (items.length > 0) // handle modifying attributes if ((splitItems != null) && (splitItems.assocItems != null)) doModifyAssocs(objInfo, splitItems.assocItems, jt);
Copyright © 2013 CA.
All rights reserved.
|
|