“Never give up on a dream just because of the time it will take to accomplish it. The time will pass anyway.”
— Earl Nightingale
We have one more function left in our Script Include that was referenced in the set-process function of our widget that still needs to be created. Last time, we completed the function that creates the Service Account, and now we need to build the one that calls the new instance registration process on the Host instance, which also does not exist as yet, either. In fact, before we build the function that uses the service, we should probably create the service first. This will be another Scripted REST API similar to the one that we already created for the Host info service, but this one will be much more complicated.
When we register a new Client instance with the Host, the following things should occur:
- The new Client instance should be added to the Host database,
- The new Client instance data should be pushed to the databases of all of the existing instances, and
- The new Client instance should be updated with a full list of all of the existing instances.
When this process is complete, all instances, including the new instance, should have a full list of every other instance registered with the Host. However, it seems to me that the registration process itself should not have to wait until all of the instances have been made aware of each other. Once we insert the new instance into the Host database, we should be able to respond to the caller that the registration has been completed, and then pushing the details out to all of the instances could be handled off-line in some other async process. But before we worry too much about all of that, let’s get to creating the service.
We need to create another Scripted REST API Resource, but we can tuck it underneath same the Scripted REST API Service that we already created for our earlier info resource. This one we will call register, which will give it the following URI:
/api/x_11556_col_store/v1/register
This time, we will set the HTTP Method to POST, since we will be accepting input from the client instance in JSON format in the body of the request.
For our Script, we will push the majority of the code over into yet another new function in our Script Include, and then use the results to populate the response.
(function process(request, response) {
var data = {};
if (request.body && request.body.data) {
data = request.body.data;
}
var result = new CollaborationStoreUtils().processRegistrationRequest(data);
response.setBody(result.body);
response.setStatus(result.status);
})(request, response);
Unlike our earlier /info service, we will want to require authentication for this service (which is why we created the Service Accounts), so under the Security tab, we will check the Requires authentication checkbox.
Under the Content Negotiation tab, we will set both the Supported request formats and the Supported response formats to application/json, as we will expect the caller to send us a JSON string containing the details of their instance, and we will be responding with a JSON string containing the outcome of the registration process.
Once we Save the new resource, it should appear in the Related List at the bottom of the service form.
With that out of the way, now we need to turn our attention to building out the non-existent Script Include function that we referenced in the resource’s script. That’s where all of magic will happen, and quite a lot will go on there, so that seems like a good subject for our next installment.
