Best practice in debugging AFX connectors?

[DavidHorwath]

Seen a couple of questions here where we all stumble into pretty much same situation:

"AFX connector is having a problem, and error message is not that helpful"

I guess I seen a tip that you can increase logging levels in /home/oracle/AFX/mule/apps/AFX-CONN-{YOUR_CONNECTOR_NAME}/classes/log4j.xml -> but that file gets overwritten if a change is made to the connector (for example through the GUI)

So what is the best practise when debugging AFX connectors?

When approaching your first integration using AFX, then what logs do you need to get in place, do not loose a lot of time. I feel I need some tips, so why not ask the community?

Example of futile error searching:

I got a newbie error over and over again when doing a basic db-table AFX-connector: Always the same error: "Invalid column index". So I checked my SQL, over and over and over again. But not a single debug level allowed me to "see" the SQL-query that was being sent by Mule. If I have had the possibility to see what actual query was being sent, then maybe I would have seen what was going on.

So is log4j.xml the way to go?

If so, which classes?

And always curious if this can be done in the ACM GUI, because then it would be more "best practise" right?

For example: Can't find the class "org.mule" in the log options for ACM.

[DebasishBhattac · Accepted solution]

As of now setting the connector specific logs are not doable from ACM.

Here is a quick excerpts from an internal wiki I wrote recently about how to enable debug log for connectors:

Enabling debug logs in AFX

1. Go to the $AFX_HOME
2. And then to go to the respective connector’s deployed location. For example, if the connector name is ‘testADConnector’, go to $AFX_HOME/esb/apps/AFX_CONN-testADCOnnetcor/classes.
3. Locate the file log4j.xml.
4. Edit the level value from “INFO” to “DEBUG” for logger name=”org.mule”.
5. Do similar changes for org.mule.api.processor.LoggerMessageProcessor",“org.mule.module.scripting.component.Scriptable" and “org.mule.component.ComponentLifecycleManager”.
6. Edit the level value from “INFO” to “DEBUG” for respective transports. For example, if you are debugging Active Directory or LDAP connectors then do it for logger name =”com.novell.ldap”.
7. Similarly if you are using a SSH connector then do the same for logger name = "org.mule.transport.ssh”.
8. We would suggest not enabling the debug for the logger "com.aveksa.AFX.server.runtime.mule.core.ExpressionResultToPayloadMapTransformer" as it will log the entire payload and that may contains sensitive information such as passwords.

To enable more connector debug logs, follow the below steps:

• Open the connector-flow.xml file from $AFX_HOME/esb/apps/AFX-CONN-<Connector-Endpoint>/

Change the logger level to “INFO” from “DEBUG” and save the changes.

• Run the following command on mule-config.xml from same location ($AFX_HOME/esb/apps/AFX-CONN-<Connector-Endpoint>/)

touch mule-config.xml

• Test/Run the capability and check the logs enabled from mule.AFX-CONN-<Connector-Endpoint>.log at $AFX_HOME/esb/logs.

AD Connector Debugging Tips

Some Generic Errors:

java.net.UnknownHostExceptionThis can occur due to following reasons:  host name is incorrect, Active Directory server is not accessible from the RSA Via L&G AFX server or no network connectivity is available, etc. To verify the host name, “ping <host name/IP>” command can be used.

javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target. In that case make sure the AD server certificate is imported in the default trust-store depending on the JVM or application server.

AFX Brief Messages:

1. “LDAPException: Cannot connect to server. Please check the host and port settings” – This is derived from the error due to connectivity as mentioned above.
2. “LDAPException: The object does not support this operation. Please check the Account/Group values" – you can get this message if the account DN, Group DN are incorrectly passed.
3. “LDAPException: Operations error, likely cannot bind to server. Please check the bindDN and password" – This kind of error happens when the bind credentials are incorrect.
4. “LDAPException: Server refused to perform operation. Ensure that you are using a secure port (e.g. 636) for this operation" – you will get this message if the LDAP server is not willing to perform.
5. For CreateAccount and ResetPassword verb: “LDAPException: Server refused to perform operation. Password does not meet complexity requirements (e.g. too short)" – you can this message irrespective of using a secure connection if the password does not conform to the AD password policy
6. For EnableAccount and DisableAccount verb: “LDAPException: Server refused to perform operation. Make sure a password is set for the account (requires secure port e.g. 636)" – you can get this message if the account may not have an password

[DavidHorwath]

Thanks for getting at least one reply. *thumbs-up*

And I have tried to use the settings in log4j.xml for that AFX-connector I am developing.

Although there is one problem with the approach:

When changing any setting in ACM web interface (Aveksa) the AFX connector gets undeployed, and in that same moment it removes your debug settings in "log4j.xml". So in practise I stopped using log4j.xml, unless there is something very specific I am looking for.

Like if I want to know what data is being sent to AFX, then I activate debug on this specific class:

org.mule.transformer.TransformerTemplate

Still there are lots of logs that are missing for me to be able to develop in an efficient matter, so please feel free to make more suggestions. Like I still miss a way of seeing the actual SQL being sent by the AFX when making a db-connector.

[PanuMlkki]

I'd be interested to know as well. I had a problem with AD provisioning at some point and simply didn't understand what was happening and why the add-operation failed. Eventually -- since I was working with my own lab -- I installed Wireshark to Active Directory domain controller and traced the TCP-traffic that was going back and forth. From there I was able to pinpoint the problem. So I had to go on a really low level. But I will have to test the above tips at some point. It could be that there are some log-settings I didn't enable etc.