Hi,
I've seen the same topic that, I am interested in is already raised so, I would like to bring out the following scenario which is still not working for me. I am trying to move an account from 1 OU to another in AD (further I will need the same for OpenLDAP as well) whenever its being requested account deletion. This is the WF that I am using currently. The WF I use originally was the AFX default fulfillment, but I have reworked it as it has to perform some specific scenario.
For moving the account in another OU, I redirected the start to a derision node Is Account Deletion (true/false) in order not to pass trough the AFX Fullfilment Handler because the account will be deleted (I need it only moved in other OU). Right?
Then I have the following query:
select
'CN=' || '${jobUserData_Z3ID}' ||
',OU=Tenant A,OU=Users,OU=Test,OU=Test1,DC=access,DC=example,DC=com' as OLD_DN,
'OU=Tenant B,OU=Users,OU=Test,OU=Test1,DC=access,DC=example,DC=com' as NEW_DN
from dual
I have already predefined the variable '${jobUserData_Z3ID}' in the other sql select node. Actually the variable is the user ID itself.
Provisioning node accordingly has the variables of the sql select node:
If I execute a change request the variable values are being presented in the WF:
The request complete successfully but, if I check in AD the Account is not being moved, its still in the same OU e.g. OU=Tenant A
AFX connector, Move an Account capability mapping, I left empty because values are being taken from the provisioning node right ? Also here should not be used AFXCUSTOM_ (as I am using it successfully for specific account attribute values population in case of an account creation only).
Does anyone have a clue what might be missed ?
Thanks.
Hi Viktor,
The provisioning command works as an ad-hoc command to fire a single capability (AFX request) where it is not reliant on the AFX fulfillment handler. The AFX capability parameter attribute values are not counted in any provisioning command where it requires values from the workflow, dis-regarding any attribute configured in any capability parameter at the connector's side.
Turning the connector to test, the provisioning command still is getting it's parameter values from the workflow. The only reason the CR didn't bring up any errors/messages was that the provisioning commands works the same whether the connector's state is 'Test' or 'Active'. So you are basically doing the same thing with the connector being in 'Test' state.
To test the capability, I've recorded a 1 minute video of how to do so which can define more where the problem is at, by checking the processing error if the ad-hoc capability action failed.
https://Dell.zoom.us/rec/share/-uFKL5up3zlJU6uWxl_PBZBiM6Dheaa82icar6FZz0z5hxMy6vf7hNdgihXFBXfv
In conjunction with this, have the AFX connector log file tailed, possibly as well with DEBUG if the error coming from the test doesn't make much sense or if there is no error.