In the Web Bridge section, we mentioned that you still need to configure the Call Bridge services to become aware of each Web Bridge service. Unless there is a direct one-to-one mapping of Call Bridges to Web Bridges, this configuration must be done via the API. This configuration requires us to use the POST request. Recall that you have deployed the Web Bridge service on all three CMS servers.
For this operation, you will need to use POST method of the /webBridges part of the API. It is worth pointing out that even though you just configured Web Bridge-related items on the CLI, they are not populated in the database. For instance, if you click to perform a GET on the webBridges object on CMS1a: https://cms1a.pod2.cms.lab:8443/api/v1/webBridges ( / ), you'll see there are a total of 0 Web Bridges reported. This may come as a surprise as you have done some Web Bridge configuration already on the CLI. None of that configuration gets stored in the shared database, from which the API gets its information. To let Call Bridge know about the Web Bridge services you have enabled, you must add them to the database via the API.
Let us take a look at the requirements for a POST to the webBridges object in the API guide.
As is often the case, there are a lot of options. There is no * by any parameter, which indicates the field is required for the API, however to create a usable Web Bridge, you need to at least specify the url parameter. You are configuring the Call Bridge and telling it the URL of the Web Bridge. Recall the Web Bridge URL was configured to use the default port, so the URL is, for instance, simply https://cms1a.pod2.cms.lab.
You will notice the Body of the response will be blank on the bottom half of the screen, however Postman indicates the response status code next to the Status: field which should be 200 OK indicating that the request was processed successfully. You have now added one Web Bridge. Follow these steps to add the other two, then check the status:
You should now have all the Web Bridges configured. Follow these steps to go back and confirm the three servers are entered properly.
If you followed the previous instructions correctly, you should now see all three Web Bridges on the list. You will notice that the output does not provide much detail. Many API requests will only return a UUID value for the object and you must query that object to get additional information about it. Note that the UUID values are unique and generated automatically, so the UUID values you see in this document will not match those in your environment. It is critical that any time you need a UUID value that you copy it from the output of your Postman client and not from this web page.
This gives you the detailed configuration for this particular object. As you can see, some of the optional parameters that were specified in the API reference are shown. Referencing an object by ID as we just did is also how we will later modify (PUT) and/or delete (DELETE) objects. At this point, your Web Bridge and Call Bridge services should be functional. For it to be usable by end users, we will need to have accounts for them to log into.