Skip navigation
All Places > Products > RSA Identity Governance & Lifecycle > Blog > Author: Daniel Cinnamon

Pretty informal post here- I just finished troubleshooting an issue with AFX at a client site.  It's an error I've seen before and wanted to give a shout out because others are likely to run into it as well.

 

They were having issues with the server not fully starting up.  In the mule_ee.log file, there was a complaint about "address already in use".

 

This is an error I've seen before, and it's because SPLUNK uses port 8089 as one of it's defaults, which AFX also requires for web service asynchronous callback functionality.

 

The easiest way to get around this issue is to modify /home/oracle/AFX/esb/lib/user/afx-config.properties, and modify the afx.async.callback.port parameter to a port that's not in use by the system.

 

I do think it'd be a good idea to get a callout in our install guide, knowing that splunk is a pretty common service to have running on a server, but wanted to get something out there in case it helps someone.

Ever since provisioning nodes were released in version 6.8.1, I've had a love/hate relationship with them.  On the one hand, they allow you to execute pretty much any sort of provisioning in your workflow (at the risk of turning workflow into a scripting language).

However, up until relatively recently, they've been very bad at reporting their status.  Did that command execute properly?  Did your account get setup the way you want?  Do we need to let support know that a person may not have the proper configuration? I don't know!

 

Well- good news- because as of 6.9.1 patch 6- there is now a way to do this right within workflow!  Let's walk through it quickly.

 

First, as of 6.9.1 patch 6, you'll notice a new checkbox on the provisioning command node.  This will force the node to wait for a response from AFX, and store that response in workflow variables.

After the command executes, there are now 2 new workflow variables available to you.

 

acm.provisioningCommandStatusCode

     -0 = Success

     -1 = Failure

 

 

acm.provisioningCommandStatusMessage

     Contains the text failure message from AFX.

 

What's not immediately clear is how to actually use these variables... they don't show up in the UI anywhere.  Here's how:

 

${jobUserData_acm.provisioningCommandStatusCode} and

${jobUserData_acm.provisioningCommandStatusMessage}

 

I've found that the decision node can't use these directly- so I created job level variables like so:

(this can be done by right clicking on any blank space on the workflow job, and selecting "properties" from the context menu).

I then set this value equal to ${jobUserData_acm.provisioningCommandStatusCode} using a set variable node.

and finally I use a decision node to branch differently based upon the result (can send email, etc).

 

I hope this helps you create more robust workflows!