IDM Designer and workflow activities allow for various entity operations, namely Create, Modify, and Delete operations.

There is no entity operation to move an object, and none to rename.

As a workaround you may consider writing some driver that does the move/rename for you, but imagine how much easier your life could be with a Move/Rename entity operation within the workflow.

Here's an easy way to accomplish this.

The key element in this Cool Solution is a mapping activity named "Rename/Move" where all the logic is encapsulated. If you are in a hurry, just take a look at that activity.

The rest of this article illustrates step by step, how to use this activity in a simple test workflow.

Instructions to create a simple Rename/Move workflow:

Start your IDM Designer and create a simple "No Approval" workflow with 4 elements:

• Start

• Mapping Activity

• Workflow Status

• Finish

In the request form, we will use 3 input fields:

fldObjectDn holds the source DN of the object that you'd like to move (e.g., "cn=testUser,ou=test_a,o=test")

fldNewCn holds the target CN (e.g., "newName")

fldNewOu holds the target container (e.g., "ou=test_b,o=test")

The program logic allows you to change both, target CN and target OU, thereby enabling a simple rename (different CN, same OU), a simple move (same CN, different OU), or a combined rename/move (different CN, different OU)

For the sake of testing and simplicity you may use simple text fields; alternatively use more fancy fields like object selectors.



Use post activity Data Item Mapping to transport your input into the workflow.



The key element of this sample is the mapping activity (that we use to emulate the Move/Rename entity activity).



Add a Data Item Mapping and use the following code segment in the source expression.

function ldapRenameOrMove( dnOld, dnNew )
{
	Packages.java.lang.System.out.println( 
                "ldapRenameOrMove ( '"   dnOld   "', '"   dnNew   "' ) " );
	var result = "";
	try
	{
		var ctx = Packages.com.sssw.fw.directory.api.EboDirectoryFactory.getConnMgr().getAdminContext( false );
		ctx.rename( dnOld, dnNew );
		Packages.java.lang.System.out.println(result);
		ctx.close();
		result = dnNew;
	}
	catch (e) 
	{
		result =  " ldapRenameOrMove () "   e.toString();
		Packages.java.lang.System.out.println(result);
	}
	return( result );
}

ldapRenameOrMove( 
	flowdata.get('start/request_form/fldObjectDn'),  
	"cn="   flowdata.get('start/request_form/fldNewCn') 
	  ","   flowdata.get('start/request_form/fldNewOu') )

Background:

We are using straight LDAP calls (ctx.rename) to do the Rename/Move.

Instead of establishing a new context with host names, credentials and such, we are using the method getAdminContext() to let IDM pass us its Admin LDAP context; this means we're acting with admin rights.

Use a target expression of your choice (like" flowdata.start/group/success"); you may use it to validate the operation's success.

Well, that's about it. Deploy the Workflow and do your tests.

Notes:
Obviously, there are some generic considerations and side effects when moving objects in your tree:

Be aware that after moving/renaming objects you need to allow some time for eDirectory synchronization before doing further operations (modify/move/rename) on the same object.

To enforce a delay after the move, you may consider adding a dummy approval step (60 seconds timeout approves) after the move action.

Since the workflow engine is unaware of the programmatic object move, use special care when you need to operate on the object in the same workflow (notifications, entity operations and the like).

If you move objects that have workflows in progress, you might see errors on these old workflows, since they reference users and groups by their DN. Moved user will not be able to see their old workflows.

Consider such side effects before moving objects around.

This approach has successfully been tested in RBPM 3.7 and IDM 4.0