MV to anything … sure, why not?

In the U2 forum the question was asked “Has anyone implemented Microsoft TAPI in a Universe application?” Let’s call this a FAQ and reword it as “How do we connect anything to an MV DBMS?” It doesn’t matter if you have Universe, jBase, D3, or QM. It doesn’t matter if you are talking about TAPI, scanners, weight scales, IM/chat, GPS, or any of the other interfaces that I’ve been talking about for over a decade. My answer is always the same…

TAPI is the Telephony Application Program Interface and it’s used for things like PBX systems, call routing, faxes, and other things related to the telephone. SAPI is the Speech API, a more generic API for text-to-speech, talking web pages, talking GPS devices, and telephones that dial a number when you say the name of a person.

I’ve done various types of TAPI/SAPI integration with MV, including interfaces with Skype, Voice Response (automated menus), speech synthesis, voice recognition, and some PBX efforts. Some of you may remember a demo I did for the Pick Systems conference in 2000 where I asked my D3 system questions about live data. It responded back by voice with an animated character floating around the screen and pointing out items of interest. The same code could easily be used for a telephony application. Ironically I was working on that sort of thing a decade ago and today people are still wondering if it’s possible.

My “angle” on this whole “how do I do this with MV” topic is that I simply don’t do these things directly in MV anymore. Everyone has heard the saying “if all you know how to use is a hammer, then every problem starts to look like a nail”. Well, the same applies if you approach every problem with the Pick BASIC hammer. The MV DBMS stores, processes, and returns data really well, but I personally don’t believe it should be used as the technical engine to interface directly with many technologies and protocols. I’ve been there and done that, and enjoy the geek factor of making Pick do cool things as much as anyone, but I need to be more pragmatic about the solutions I implement for clients. BASIC is a good language for manipulating data in the MV environment but it requires platform-specific syntax and unnecessary tricks to get it to work directly with the outside world. There are a plethora of tools that already do all of these things with TAPI/SAPI and devices and protocols. There’s no need to sort of brute-force the MV platform into driving telephony hardware and APIs. Yes, it’s often desirable, as anyone using our NebulaXLite product will tell you, but it’s not necessary and often not the right approach.

The approach I use and recommend is to find tools that do these things well, and then connect them to your DBMS which does it’s job well. The telephony components and DBMS components should be at an equal tier. The telephony components provide input and output, the DBMS provides data handling. You accept requests in a telephony component, use custom code like Java, C++, VB.NET or whatever is supported to translate the request into text, query the DBMS with text, get a text response, then pass that text back to the telephony component to do whatever is required with voice or phone. Each component does what it does well – and it’s much easier to make a tool do what it does well, than to make a tool do what it wasn’t really designed to do.

Of the many advantages of separating out components like that, here are just a few: You can replace the telephony hardware or software with little or no change to your DBMS code. You can re-use your DBMS code with multiple simultaneous interfaces. You can port your DBMS code to/from U2 or any other MV platform. You can even split the load with a relational DBMS, in part because you don’t need to use platform-specific MV APIs to do the job. This is all much more difficult if you hardcode the DBMS to a specific product API.

The above approach works with telephony, scanning, scales, POS devices, web services, websites, exchanges with relational databases, and all sorts of other interfaces. Here’s a perfect example: One of my clients recently needed a signature pad at their MV-driven POS. I didn’t link the signature pad directly into MV, I wrote software to obtain a signature using standard, supported tools, and I then got the MV software to launch that utility and retrieve results. I’ll post a blog in a few days with more info about this specific interface.

Think about what the rest of the world is doing with MVC patterns, separating UI from the back-end and otherwise isolating components from one another. This sort of development is very liberating as it completely eliminates the “can I do this with MV” question and makes MV just another fully qualified tool in your kit. That increases the value of MV in the enterprise and helps to eliminate the “legacy” perception that we’re always fighting.

This is how I approach all tasks that come my way. It’s the foundation of just about everything I discuss here in my blog and the offerings that are created here at Nebula R&D. It just works, and allows me to say “yes” to every “can we do this?” inquiry that comes my way.

I hope this helps you to create whatever interface you need, but of course requests are always welcome here at Nebula R&D for related consultation and development services.