Developing solutions for the Nodinite LDAP Web API
Code or system integration platform? All options are supported!
This guide is primarily written for developers and administrators. Solution architects/Integration architects will learn how to design traceable LDAP solutions and read about common uses cases the Nodinite LDAP products supports.
The Nodinite LDAP products enable application integration solutions using either custom code (Java, C#, node.js) or some integration platform like Mule ESB or Microsoft BizTalk Server. Developers must be well versed in developing, testing and deploying solutions on selected technology.
The Nodinite LDAP products were developed to support and solve many typical problems you would otherwise encounter working with the LDAP catalogue services. Active Directory is especially tricky with often very bad error codes due to the interop/COM legacy.
Developers will find the LDAP Adapter for BizTalk very easy to use, both when developing and for advanced LDAP application integration scenarios. These solutions may keep your master data/accounts / LDAP Assets synchronized across systems and organizations.
A short example of a common use case is an insert when the object already exists. Normally you would have to perform a request operation and then evaluate the result and then conditionally perform the insert or update operation. This scenario may involve an orchestration correlating different event or complex coding. If you want to develop, design and run your LDAP enabled solutions this way this LDAP Adapter still gives you that ability. However, due to the batch-oriented way of performing operations you can send 2 batches, the first one with an insert, and then the other one with the update operation. You can allow the first batch to fail, and still move on by providing the
continueOnError parameter. This solution pattern is also known as an upsert.
Other simplifications supported is exemplified by: In one batch, send multiple operations
- 1st batch - Create a new OU (new user is part of a new department) – allow this batch to fail if OU already existed
- 2nd batch - CreateUser with arbitrary valid attributes – allow failing…
- 3rd batch - AddUserToGroup(s) one or more groups from potentially different part of the LDAP tree
- 3rd batch – Select all users in Group beginning with letters adm* (Note multiple operations in same batch 3)
This is all only one message and all search and operational results from all operations are returned in the response message. The response message in this example has 3 returning batches with search and operational result as per operation, 4 operations in total.
The LDAP products perform operations (read/write) using either a JSON or XML based message. The caller (client) should accept and use the response even though one-way operations are supported. The main reason for managing the response is that you can validate that the operation really did succeed. If used with Logging, then you will have even better traceability and means for finding and dealing with any problems that may occur.
On a high level, the Request is a message with a collection of batches. Each batch contains one or more operations. The operations are predefined making it dead easy to code the logic for your intended operations.
The Request has two parameters:
- Connection ID (a GUID) that exists in the Configuration file
- A payload with a collection of LDAP Statements (batches), these can either be XML or JSON
On a high level, the Response returns data based on a pre-defined schema. This means that you always know what is being returned.
Some ByteArray properties for example in the Active Directory are not human-readable (due to byte array representation). In both the Swagger and the Windows Forms client utility, some helper methods exists to convert to and from base64.
Managing users are further exemplified in the User Management guide.
Managing groups are further exemplified in the Group Management guide.
Managing the Schema is further exemplified in the Schema Management guide.
Managing Organizational Units (OUs) are further exemplified in the OU Management guide.
Managing the AD is further exemplified in the AD Management guide.
There are many great LDAP/AD editors/Browsers, we recommend the following:
Free open-source java based tool Apache Directory Studio, http://directory.apache.org/studio/
Installation of Apache Directory Studio requires Java JRE run-time.
Ldap Admin is a free Windows LDAP client and administration tool for LDAP directory management. This application lets you browse, search, modify, create and delete objects on LDAP server.