Using the LDAP Adapter

Body

For the first time this past week, I worked on a PMR that used the LDAP Adapter. Previously, I've only ever used the LDAP server for external authentication of user accounts, so I had the pleasure of learning a bunch of new things about LDAP and searching trees. It was much more challenging to get this thing working then I expected, even with an LDAP server already in place with accounts ready to go. Documentation for this service assumes that you already have a good working knowledge of the LDAP model, mapping and translation, and XML in general. And they really mean it too! Hopefully the example below will take some of the guessing out of the picture and help you to pull information via LDAP from a business process.

Here's a link to LDAP Adapter documentation for review.

Of course, in order to use this adapter, you need to have an LDAP server configured, up and running somewhere. I've got an OpenLDAP instance running on a server at default port 389. I also use a principal account to bind to the server and do searches. My bind account is cn=Administrator at my baseDN of dc=oxnard,dc=annarbor,dc=stercomm,dc=com. I use jXplorer, an open source LDAP browser, to view my entries on the LDAP server to see what I have to work with. It also makes it easy to experiment with your search trees and build formatting strings for searches. Here's a view of my search tree at the baseDN:

So, let's configure SBI.

First step, create an LDAP Adapter from Deployment -> Services -> Configuration. Under hostname, insert the IP, server name, or fully qualified domain name for where you connect to the LDAP server from the Sterling B2B Integrator node. You can also set values for Port, Read Timeout in secs, and Max Number of Records to Read. You will also want to Set Authentication to Yes. This was a definite gotcha for me. I was trying to pass the authentication values directly through the BPML, but unless you set it in the adapter, there would be no values to override through BPML. So, I entered the principal account for the Login Name (cn=Administrator,dc=oxnard,dc=annarbor,dc=stercomm,dc=com) and the appropriate password for that account on the next page, LDAP Authentication Setting. Without setting these credentials in the adapter, the adapter was trying to bind anonymously which resulted in an authentication error for my LDAP server configuration. Your results may vary depending on how your LDAP is locked down.

I then created a BP to try out this adapter. It's another VERY simple BP (my specialty). Here's what it looks like:

I did my testing by manually executing the business process and handing it a Primary Document from the BP Execution screen. After a few tries, I was able to get search results back with an input document like the following:

I've designated my baseDN, operation, and scope all as attributes in the request. I am also doing a search on a single criteria. The object just has to be a person. This returns all the results shown above, in a <dsml> format:

etc.etc.etc.

Now, another gotcha I ran into when trying to limit my results was that of invalid xml characters. LDAP calls for search strings such as this:

(&(objectClass=person)(sn=BS*))

This string will return all person objects with an sn field which begins with the characters BS. However, if you create your input document like this:

The LDAP service halts with this error: Operation failed : Error occured while parsing request xml. : Malformed xml: Error in root or 'request' element

We still have to take into account that this is an XML document that must be parsed by the workflow engine. So, we need to change that '&' in the search string to its HTML entity in order for it to parse correctly:

This successfully limited my returned results based on the criteria provided. The documentation includes more examples for update and delete operations as well, with templates of the input documents you should use for the adapter.

Once you have the basic functionality working, you can then build maps and translations that will execute before and after the LDAP Adapter. The pre-translation will take whatever inputs you desire and map them to an XML document similar to the <LDAPAdapter> xmls above and to be used as your search document. Post-translation will take the return XML document and map to whatever output format you desire. You may even be able to grab what you need directly from the PrimaryDocument and place it in ProcessData with some well-crafted DocToDOM assigns.

I hope this was helpful for your LDAP lookup project. If you have further questions, or specific issues with your configuration, open up a new PMR and we will see how we can help.