Veeva integration was quite a new to me as I have used it only partly as a user for review and approvers for documents. In this specific case, I had to move upwards with my Veeva knowledge. It was more about managing users and “business roles” in Veeva Safety via webservices REST API connector in IdentityIQ.
I understand that people are busy, but It surprised me that I was the only one doing research in the Veeva documentation before the initial meetings with stakeholders and Veeva representatives.
That was also the main cause for confusion with the first two initial meetings as people talking about different objects in different systems. Lucky for me, it was pretty clear and I had a good head start and overview from the beginning to mentally design the solution, or even if possible.
We decided for PoC to test the basic functionality and make the webservices connector as a base for other applications.
The Veeva’s API docs were quite sufficient to onboard, but there was/is an issue with “User Role Setup” object. It does not fit in the IGA as it is created on the go. Obviously Veeva does not have the same security model as Active Directory, but with these objects generated on the go, would bring additional customizations to IdentityIQ.
After several meetings, me and my colleague were able to propose few solutions. One of them full customization from IdentityIQ for Veeva logic and second one Veeva creating a “Business Role” object and we would manage only memberships.
To my surprise Veeva stepped up and created some kind of object that fits their security model and UPS solution, but it also simplified the way how we would manage the logic. Which would be none.
In parallel, while Veeva was developing their “Business role” solution, I have created and tested the webservices connector and made the basic PoC with User Create/Update/Enable/Disable operations and assigning and removing entitlements. That also includes aggregations for accounts and groups.
The best part I did, was that I have analyzed and debugged passed objects before and after REST end point calls. That allowed me to have a strong foundation and what actually happens during the webservices operations. The documentaiton from SailPoint was ok, but was missing a lot of information how to do things. Although they have some example rules that were quite useful.
In general I would recommend to anybody who is setting their first webservices connector, to go through the documentation, debug and inspecting the objects before and after operations. That will give you full overview and allows you to make the necessary adjustments for the custom connector details.
What SailPoint provides is the framework, the JSON/XML attributes in body or responses, you have to handle and setup. Most likely you might need to make your own authentication or at least we were for Veeva as they use sessionId.
Here is the debug logger what you can use as a good start when developing.
if (log.isDebugEnabled()){
log.debug("BODYDEBUG" + requestEndPoint.getBody());
log.debug(requestEndPoint.getFullUrl());
log.debug(requestEndPoint.getResMappingObj());
Attributes attrs=application.getAttributes();
if (attrs != null) {
for (String key: attrs.getKeys()) {
//log.debug(key + " " + attrs.getString(key));
}
} else {
log.debug("No attributes avaiable");
}
log.debug("Operation: " + requestEndPoint.getOperationType());
if (provisioningPlan != null) {
log.debug(provisioningPlan.toXml());
List accountRequests = provisioningPlan.getAccountRequests();
for (accountRequest : Util.safeIterable(accountRequests)) {
List attributeRequests = accountRequest.getAttributeRequests();
if (null == attributeRequests){
break;
}
for (attrReq : Util.safeIterable(attributeRequests)) {
if (null != attrReq){
log.debug(attrReq.getName() + " " + attrReq.getValue());
}
}
}
} else {
log.debug("No provisioningPlan");
}
}