Mobile Users Stay Connected Via Tactica Caprera, The First Offline TP Monitor

Our criteria for evaluating Caprera were comprehensive. During testing, we looked for fast, accurate database replication, including bidirectional synchronization at the column level, as well as intelligent conflict resolution. We expected to be able to connect to the network via LAN adapter, dial-up link and the Internet with reliable messaging and queuing of pending transactions. Additionally, we hoped to be able to use ODBC, JDBC (Java Database Connectivity) and native call-level interfaces to the database. An easy-to-write, understandable, event-driven script language for expressing offline data access business logic and rules was a plus, and we didn't want any constraint s forcing us to develop the user interface in a particular programming language; an OFTP monitor should offer easy administration. Finally, we wanted a secure environment that used password authentication, encryption and digital certificates. Working in an Offline World We tested Caprera's ability to handle a number of offline database update situations. Basically, we forced it to tackle a series of controlled database operations in which the transaction activity took place offline (remotely). In the first test, we observed Caprera's reaction to several offline salespeople selling, in total, more widgets than we had in stock. The second test forced Caprera to recognize and handle one offline user updating a database entity that another user had deleted. A third test revealed Caprera's treatment of multiple offline users updating the same entity. And the fourth test examined how the product dealt with multiple offline users deleting the same database entity. During these tests, we noted whether t he application behaved differently when the Caprera local database copy was used in place of the central database. We wanted to know how easily Caprera handled the processing of the deferred transactions against the central database. And we inspected the database for integrity errors after each test. Caprera scored well, passing our tests with high marks. We particularly liked its easy administration, painless integration into our VB software and its analytical approach to the complex problem of offline database access. Our database remained consistent, and the OFTP monitor's password protection and RSA-based encryption assuaged our fears when we allowed intraday remote connections to the database. Caprera's speed wasn't impressive, but performance didn't carry much weight in our evaluation because the database connections occurred intermittently--just before and just after going on the road, with occasional connections during the day. We were mildly disappointed that Caprera didn't use the triggers and constraints we had declared in our database as the key to automatically identify candidate situations requiring conflict resolution. At design time, the CapreraBuild tool could have used our database's triggers, constraints and foreign keys to construct template business logic scripts. Overall, we concluded Caprera is the right tool for the job when mobile workers have to issue database transactions while temporarily offline. Spoofing Through Persistence In the lab, Caprera's infrastructure provided our VB client application with an LPS (Local Persistent Store) in the form of Microsoft Access files. The LPS gave our simulated mobile workers copied database content to work with on the road. When the workers reconnected, Caprera applied database changes and let us resolve conflicts resulting from offline database activities by sending those conflicts to an administrator or back to the client. We successfully and rather easily connected mobile clients to Caprera Server through four of the pr oduct's connectivity options: Microsoft Exchange/MAPI (Messaging Application Programming Interface), a network adapter and TCP/IP protocol stack, RAS (Remote Access Services) and SLIP (Serial Line Internet Protocol)/ PPP. Tactica says Caprera also supports wireless cc:Mail/VIM (Vendor Independent Messaging), IBM MQSeries, MSMQ (Microsoft Message Queuing) SMTP and TCP/IP. When our warehouse was well-stocked and no database conflicts ensued, the OFTP monitor seamlessly and smoothly let our salespeople connect to the database in the morning to update widget counts and pricing, then reconnect late in the afternoon to record sales transactions in the central database. When a conflict did occur, business logic rendered in script form told Caprera how to resolve it. Using Caprera was simpler than we anticipated. Through a process of subsetting, we first told it which database tables and elements to replicate into the LPS (for example, those the client software needed). We next modified the VB client softwar e, adding two push buttons. One we labeled "Before Selling Widgets" and the other "After Selling Widgets." The code behind the first button replenished the LPS with current database content from the central database (before a mobile worker went on the road). Clicking the second button caused the VB program to invoke Caprera functions that applied LPS changes as transactions against the central database when the worker returned to the office.

For the Side Bar on Taking A CAIRful Approach Other Reviews Asset Management Products Let You Gain Network Control By Bruce Boar dman