Manage Facebook Workplace Account Management API with OSB 12.2.1

Workplace Account Management API brings you REST services to manage Workplace users in one organization. To integrate this API with OSB 12.2.1, it is necessary to know the complete structure of the request and response of the REST services. Since the structure of the content body is a bit tricky to manage, we are going to do some steps with the magic of the new JavaScript feature that is available in OSB 12.2.1.

Solution

The documentation of the API is here.

As we can see in the documentation, Workplace API is based on the SCIM-compliant (System for Cross-domain Identity Management )

The content body of the request of get user will look like this:

  
  
 
{
  "schemas": [
    "urn:scim:schemas:core:1.0",
    "urn:scim:schemas:extension:enterprise:1.0"
  ],
  "id": 11111111111,
  "userName": "juliusc@example.com",
  "name": {
    "formatted": "Julius Caesar"
  },
  "active": true,
  "emails": [
    {
      "primary": true,
      "type": "work",
      "value": "juliusc@example.com"
    }
  ],
  "addresses": [
    {
      "type": "work",
      "formatted": "Foro Italico",
      "primary": true
    }
  ],
  "urn:scim:schemas:extension:enterprise:1.0": {
    "department": "Headquarters"
  }
}
  
  

One of the workarounds is to handle the request as a string using XQuery, for example:

When we have the request complete as a string, the next step is to call the rest service and set it as JSON using a transport header.

If we want to handle the request or response as JSON and not as String in the pipeline, then there is a good feature added in OSB 12.2.1 called Javascript located in the Message Processing section.

Basically, this new component allows us to insert JavaScript code where we can create or modify existing variables in the pipeline. For example, if we want to modify the value of a field in the JSON request, we initiate with the variable called "process" just after the name of the existing variable. In this case, the variable of the request is a string, so it is parsed to Object JSON, the active field is changed to false (deactivate user), and finally, the data type is changed to string as it was before.

Conclusion

There are several solutions to achieve this integration, like using a Java callout or only handling the request and response as TEXT in the business service. The workaround that I provide fits more with the new feature of 12.2.1 (JavaScript) and is not complex at all to complete the integration.

If you have any questions, let us know!