Controlling MV by phone Part 3

In November 2010 I wrote a couple blogs about using a telephone to interface with MV applications. After completing a few successful projects I decided to make the interface a bit more generic for others to use. Here’s some info on that effort.

The original interfaces worked well but they were “one hit wonders”. As an example, someone could SMS a part ID to a number in their contact list and the return data would include a product description, cost, price, and current on-hand quantity. The way these interfaces work is that the phone call is translated into an HTTP request, a web server parses the request and sends it into MV, the response from MV is nicely formatted, and the response is sent back as a return SMS. The problem with this is that the middle tier “web service” is parsing the request and formatting the response. A new request requires a new effort at the middle tier. I was originally using OOP techniques in the middle tier, with a class called Inventory that was populated from data returned from the MV DBMS. The output formatting was then hard-coded with something like this:

response += "Available: " + inventoryItem.Available

While that’s very clean code, it’s over-coding for this scenario. I decided to put the responsibility for parsing and formatting into MV BASIC. This would allow any BASIC developer to process any request and return any response. No further assistance is required from me to process a new request/response pair.

Information that comes in with every SMS request includes the originating From phone number, the destination To phone number, and of course the Body of the text message itself. The middle tier now formats that data into a common dynamic array and passes that data into the MV server. The BASIC programmer can do whatever they want with the data received. The format of the SMS text Body is up to them. Using all of the data, the response is returned simply by passing back another dynamic array variable, or by using CRT to display text which gets captured and returned via SMS to the caller. The method used to return the data depends on the connectivity mechanism, which I’ll describe in a minute, but the point here is that the I/O is completely familiar to every Pick programmer – there’s nothing special about any of this and nothing new to learn to make it all work.

If this is going to be a general purpose tool, I wanted it to be usable in a wide variety of MV sites, with different DBMS platforms and different connectivity methods. As a bonus feature of this recent development, I’ve created a general interface to many common connectivity methods. This allows the middle-tier to pass requests to a variety of MV environments using whatever connectivity mechanism is available. Here are some examples:

• QMClient to QM over any OS
• UO.NET to Universe or Unidata
• New TigerLogic MVSP to D3 or mvBase
• mv.NET to any MV DBMS

Finally, there is an SSH interface which allows the middle tier to SSH into any server, process any command, and return whatever results are available. I have a client with D3 where the only interface to the server is via SSH. So now the code can SSH into their Linux box, use the d3tcl command to pass in the request, execute a program, and return the results.

Again, I just have one code set for all of the above connectivity methods. The connectivity is decided at run-time with a XML configuration file. The file has one setting to identify the connectivity method. There are then many other settings for the Server IP or Host, User/Password info, specific commands to execute or programs to run, and any other details that need to be sent to a system in order to effect a login and execution.

The take-away from all of this is that any MV system can now process and respond to any SMS queries with nothing more than BASIC code. Because of the connectivity methods, many sites won’t even need to install anything at all, just write some BASIC code, and we can connect in from the outside to execute their code. I think that’s pretty cool.

So what happens from here?

Well, SMS is very powerful and can be used by sysadmins as well as consumers. I need to find people with a vision for using this new UI so that we can deploy this solution for a variety of applications, and see what other refinements are necessary. If any VAR or application developer reading this thinks it sounds interesting, but can’t think of ways to use it, email me and I’m sure we can come up with ideas. I’ll help you to pitch this to clients and management.

I’m sure the connectivity will need to be enhanced to accommodate details that we find at various sites. A lot more testing needs to be done before I can “certify” that all of the connectivity methods described above are fully supported.

This can be used for voice processing as well, though of course that’s more complex. In this scenario, someone makes a normal phone call and they get an automated attendant. To start, does the attendant do a lookup on the callerID to see if the caller is recognized? Will we accept the call from this person at all? If we accept the call, do we transfer to someone or do we read off a menu? If the caller responds to the menu, we need to know what to do with each possible keypad press. This is what’s required for a virtual phone system, a VBX, and I’ve done a lot of work in this area recently too. Effort will be based on demand to create a voice interface that’s easy to use as the SMS interface. Again, if you’re interested in this, let’s talk, because I already have a solution available, it’s just not “productized” yet.

Finally, the general purpose connectivity interface is itself kinda neat. I created an API that allows my “client” code to either run a BASIC subroutine or to execute a TCL or OS command, and it will do this on any system using the chosen protocol. So as a developer I don’t need to know ahead of time what connectivity the end-user site will have, nor which DBMS they have. That’s powerful. I’m going to look into using this for some other applets, and I might even sell this interface as a product of its own.

As always, comments and questions about all of the above are most welcome!