Saturday, October 30, 2004
The Future for Horizon is SQL?
At MTI, we often get asked about when we're going to support SQL Server or other database technologies. Usually this comes up in internal meetings when we have problems with customers running FoxPro or corrupt indices have driven our customer support nuts but I recently demo'd Horizon to a Great Plains reseller who was really struggling with the whole "but you don't use SQL Server" argument.
By the end of the meeting, he was really excited about Horizon and here's why:
1. This is a DESKTOP application that can also run on the network so if someone has one machine, they can use it. If they have ten machines, they can also use it. Low overhead. Yeah!!!
2. It's HOOKABLE. Want to update your SQL Server database whenever a load is saved? We can DO that with a service call. Driver Assigned to a shipment? Send an update message to the SQL server. In fact, one could track all of the standard Horizon events and populate the SQL with either direct stored procedure calls OR XML DiffGrams or UpdateGrams if we wanted to.
This last bit is EXTREMELY important - especially if we want to take this concept further. I was demoing to a prospect where the dispatcher is actually out on the road all day. Equipped with a laptop, he could likely do all his updates in Horizon. If the laptop was connected to the Internet, the updates could go out across that connection. If it wasn't connected, we could build up a "queue" of events. Think of it. I'm disconnected, running locally. I do all my work - when I'm finished, the next time I'm connected to the network -> off goes my information in SEQUENTIAL transactions allowing it to be updated.
This is almost like a take-off from the ASCII Translator scenario that Riteway, one of our customers with remote terminals, use. They want us to support the Internet with ASCII Translator. Why not? You export the data -> we FTP it to a server, then the main office downloads it from the server. Likewise the update takes place much in the same fashion.
No - it may not be real time but the reality of disconnected data sets is that it very rarely is.
I know some members on the team are putting a lot of effort into moving to SQL , etc but the entire scope of the project hasn't even been really figured out yet. They're still trying to figure out exactly what the next step is. We know where we want to get to - but it's that first step that seems to be confusing people.
Come on - it's easy and Horizon is already designed this way so it's not hard to do.
Step 1. Convert ASCII Translator to do automatic FTP updates over the Internet. Maybe even make it run as a Message Monitor service so it happens behind the scenes. (oohh- that's a neat idea)
Step 2. Set up an Update Service in Horizon so that any time something happens, it's logged either into an XML output, SQL stored procedure update or ASCII output. Start with the easy ones like : Save Checkcall, Deliver Shipment, Pickup Shipment, Book Order, Assign stuff. That's the core part of the business anyways.
Step 3: Get an updated Translator that either posts XML DiffGrams or SQL Stored Procedure calls to a server in the back end.
Now for large third party accounting integration, that updated Translator can be making calls to the Accounting engine's updates or whatever.
You know - yes, it's not making Horizon use a SQL Server backend - but we've got other projects going on to offer SQL Server technology. But wouldn't it be awesome if using this approach, we can offer a distributed database with our existing technology that also updates larger databases as needed. Using that same translator approach, we could write an easy PDA app that does the same thing.
Cripes - I hate this sometimes. Now I'm super excited about taking this to the next level and I know there will be resistance. There should be - we want to create the next generation of product so why try to create similar technology offerings in our current product? Why? Because we can do it.
Quickly. Easily. Efficiently.
This information is not the official position of MTI or Melton Technologies or its affiliates.
By the end of the meeting, he was really excited about Horizon and here's why:
1. This is a DESKTOP application that can also run on the network so if someone has one machine, they can use it. If they have ten machines, they can also use it. Low overhead. Yeah!!!
2. It's HOOKABLE. Want to update your SQL Server database whenever a load is saved? We can DO that with a service call. Driver Assigned to a shipment? Send an update message to the SQL server. In fact, one could track all of the standard Horizon events and populate the SQL with either direct stored procedure calls OR XML DiffGrams or UpdateGrams if we wanted to.
This last bit is EXTREMELY important - especially if we want to take this concept further. I was demoing to a prospect where the dispatcher is actually out on the road all day. Equipped with a laptop, he could likely do all his updates in Horizon. If the laptop was connected to the Internet, the updates could go out across that connection. If it wasn't connected, we could build up a "queue" of events. Think of it. I'm disconnected, running locally. I do all my work - when I'm finished, the next time I'm connected to the network -> off goes my information in SEQUENTIAL transactions allowing it to be updated.
This is almost like a take-off from the ASCII Translator scenario that Riteway, one of our customers with remote terminals, use. They want us to support the Internet with ASCII Translator. Why not? You export the data -> we FTP it to a server, then the main office downloads it from the server. Likewise the update takes place much in the same fashion.
No - it may not be real time but the reality of disconnected data sets is that it very rarely is.
I know some members on the team are putting a lot of effort into moving to SQL , etc but the entire scope of the project hasn't even been really figured out yet. They're still trying to figure out exactly what the next step is. We know where we want to get to - but it's that first step that seems to be confusing people.
Come on - it's easy and Horizon is already designed this way so it's not hard to do.
Step 1. Convert ASCII Translator to do automatic FTP updates over the Internet. Maybe even make it run as a Message Monitor service so it happens behind the scenes. (oohh- that's a neat idea)
Step 2. Set up an Update Service in Horizon so that any time something happens, it's logged either into an XML output, SQL stored procedure update or ASCII output. Start with the easy ones like : Save Checkcall, Deliver Shipment, Pickup Shipment, Book Order, Assign stuff. That's the core part of the business anyways.
Step 3: Get an updated Translator that either posts XML DiffGrams or SQL Stored Procedure calls to a server in the back end.
Now for large third party accounting integration, that updated Translator can be making calls to the Accounting engine's updates or whatever.
You know - yes, it's not making Horizon use a SQL Server backend - but we've got other projects going on to offer SQL Server technology. But wouldn't it be awesome if using this approach, we can offer a distributed database with our existing technology that also updates larger databases as needed. Using that same translator approach, we could write an easy PDA app that does the same thing.
Cripes - I hate this sometimes. Now I'm super excited about taking this to the next level and I know there will be resistance. There should be - we want to create the next generation of product so why try to create similar technology offerings in our current product? Why? Because we can do it.
Quickly. Easily. Efficiently.
This information is not the official position of MTI or Melton Technologies or its affiliates.
