In any event, enable the “Allowed to use reporting API” and “Allowed to Use Command API” privileges.
Everything and More
All API examples presented in this post are based on the API Programmer's Guide 1.8.0 that’s available here: http://www.bomgar.com/docs/content/documents/bomgar-api-guide-1.8.0.pdf. The web-based API is enormously full-featured and contains methods for tightly integrating Bomgar with incident tracking and workstation management products. Projects of that scale make use of the XML data files and the Bomgar outbound event triggers for client-server architectures. For our purposes, we’re concerned with just the few pages devoted to session start.
Let’s begin with the simplest command that starts a session in the General Queue. Such a command looks like this:
You can test these commands out by substituting your actual domain name for the your.domain.com place holder in the example above and then pasting the result into a browser address field. Once you craft the final syntax of the API call, you will use it in the HTML code of the web page as a hyperlink probably associated with a graphic or icon of some sort. Here’s an HTML example that hyperlinks a line of text:
<p><a href="https://your.domain.com/api/start_session.ns?issue_menu=1">Click here to start a remote support session.</a></p>
Imagine placing a link such as this at the end of a self-help tutorial on a Frequently Asked Questions web page. If the customer’s issue is not resolved by following the self-help, they could immediately request assistance from a service technician without having to navigate away from the self-help page over to the Bomgar portal page.
The above command simply pops the remote customer into the General Queue; but since in our imaginations they are perusing a self-help web page, that implies that they have a specific issue. Wouldn’t it be nice if the API call would specify that issue and automatically route the incoming session request to the appropriate team? Good news! All it takes is one tiny addition to the API call.
In this example the id parameter at the end of the API call identifies an issue that’s associated with a team. Teams and their issues are defined in the /login administrative interface under Configuration>Support Teams. But here is a possible complication. As you might be aware, issue submission on the Bomgar portal page optionally can be configured to identify available service technicians instead of team issues. If that’s the case then the id parameter would identify a particular service technician. Since using Issue Submission to identify service technicians is a relatively rare use case, I won’t cover that here. However, if you’re interested in that implementation option it’s covered in the API Programmer's Guide.
Can you chat for moment?
So far our examples have involved downloading the Customer Client and starting a full remote support session. But perhaps you’d like to initiate a Bomgar Click-to-Chat interaction before launching remote control. The simple way to do that is to add a parameter to the above examples. For instance, let’s add c2cjs=1 to our request to start a session in the general queue. The resulting command looks like this:
How about the other side?
The Bomgar API can be used to streamline service technician activities as well as making life easier for your remote customers. Bomgar offers a client scripting API that can:
- Start a support session with a specific Jump Client
- Prompt service technicians to create session keys
- Start a vPro session with a specific remote computer
- Start the Bomgar Representative Console application
These are very powerful capabilities and I’ll provide just one example in order to show that power doesn’t always equal complexity. Suppose your workstation management product has a web interface that lists all your computer assets and that you have installed Bomgar Jump Clients on some of these computers. With just a little bit of scripting, you could add the ability for a service technician to launch a Bomgar support session directly from the workstation management interface. How cool is that?
First let’s look at the API call and then examine how it works:
The operative pieces of this call are the commands start_pinned_client and search_string. The start_pinned_client portion is pretty self-explanatory; so let’s look at the other parameter.
The search_string identifies the target computer and this can specify a variety of criteria. In my example above, the target is identified by hostname as it appears in a Representative Console list of Jump Clients. Other criteria can be used, including the contents of the comment field, the public IP address, or the private IP address. If the search_string matches more than one Jump Client, then the service technician receives a prompt to choose which target in order to complete the jump. And if the service technician is not logged into their Bomgar Representative Console application, the console will be started and the technician will be prompted to log in.
Where do we go from here?
We’ve barely scratched the surface of all the activities that can be done with the Bomgar application programming interface. The intent of this post is to stir your imaginations and foster new methods to streamline the support process while improving the efficiency of your service desk and offering improved service to your remote customers. Much can be accomplished with even the simple commands covered above; and, if desired, the API can be leveraged with much more complex integrations to enable Bomgar to work with CRM products, incident tracking systems, call routing and management components, statistical tracking and reporting, as well as workstation management products such as Dell KACE.