Recently I wrote an article that was entitled, “Why Actian DataConnect Goes Head to Head with the Big Boys”. I thought it might be beneficial to show a use-case for why this is important.
As a developer and data integrator, there are many concepts that are important when designing a product. Some of these are Repeatability, Scalability, Stability, Reliability, Usability, and more. I have two great examples where DataConnect meets this mark.
The first use case was a project for a Customer that used an ERP solution for Government Contractors, called Deltek Costpoint. In late 2008, I built 5 integrations that fed data into Costpoint, or pulled data out of Costpoint and sent it outbound to a 3rd party company using Maximus. These integrations went through customer acceptance testing with few changes needed during the first three months, and very minor changes since then. The great thing about these integrations is that they have been running consistently and reliably for more than 6 years without any maintenance. This speaks highly for the product in terms of Stability and Reliability.
The process below takes an Inbound file from IBM Maximo (Enterprise software used track the operation, maintenance and disposal of assets), and builds out a work order in Deltek’s Costpoint.
Ralph Huybrechts, CFO of the Keta Group, LLC, had this to say, “We contracted with Deltek, the software supplier, who assigned David Byrd to write several Pervasive integrations between the prime and subcontractor’s accounting and timekeeping software and Maximo. David wrote, tested and finalized these integrations in a 45-day phase-in period prior to the start of our large base operations support contract with the Army. This contract requires 350 employees and handles 5,000 service orders per month. The integrations have performed flawlessly since the start of the contract in 2010.
The second example I recently spoke about in another article called “Web-Services Best Practice: Using parallel queueing to streamline web-service data loads” and how it is important. For this use case, I designed an integration that would run Accumulator Webservices messages, as well as others, that were stored in a database table. These messages were created by multiple integrations and fed into the table. Here is the cool part – a single integration picks up these different types of messages and then sets the connection parameters on the fly from data stored in the table with the message like the URL endpoint, the user & password credentials and seamlessly processes the web service call and stores the response in the table for later processing. Simply put, this integration connects to multiple Web-Service endpoints without hardcoding the required parameters in the integration, thereby demonstrating Scalability.
The process below reads a database table for messages to process, takes that message and required credentials, and submits the message to a webservices, waits for the response and stores that back in a table. In addition, the process is run from the command line where a queue number is passed in. This process using similar bat files has run 75 queues at the same time.
But it goes further, the same design concept can be taken a step further using Oracle CX endpoints. One might consider a similar integration to load Oracle Sales Cloud from data provided from exports from CRM on Demand, however, this is could run into some issues with CRM On Demand Attachments, especially large ones. The bulk export out of CRM OnDemand provides all the small file attachments, but not the large ones. It can provide their Attachment ID, which you feed into the database via CRM Attachment Export requests in bulk, and store each attachment in the database response. So, in this case, not only is data fed into a web service for loading but also to fetch data out of a web service, all through this single integration. The best part of this integration design is that the integration does not care where the XML Message came from or is going to, it just takes the message, connects, and sends it, and then stores the response. This is the height of Repeatability.
The process below is very similar to the process written above. In fact, it pretty much does the same thing. The first exception here is the different types of messages are not going into Healthedge (a solution for the healthcare payor market), they are actually used in a data migration project taking data export from Oracle CRM on Demand, which is then built into message which will be loaded to Oracle Sales Cloud. And the second exception is that this was built in Actian DataConnect V10.
The Bat file below is very similar to the above process. It shows the differences in running a v10 process from the command line compared to DataConnect v9.
Chris Fuller-Wigg, Director of Sales Automated Services, stated, “The efficiency gains we experienced when loading data in parallel is kind of unreal, almost 10x faster than serial. We found ourselves losing a whole day for Accounts to load, only to push the button to load Contacts the following day. Cutting out the wait time and letting the system process multiple loads at once allows us to load data 1.5 weeks earlier on average.”
Lawrence Chan, Sr Sales Automated Services Consultant, added, “The value of this solution is not only limited to the incredible improvements in data migration speed. With one click, we can have your system’s data up to date the day before going live with one click of a button. With proper planning in place, those late nights getting your data up to date will be a thing of the past.”
The fact the Actian DataConnect can be found to fulfill the meaning of these terms satisfies the ultimate customer experience. The customer here is two-fold, the first is the developer being able to define and build a trusted flexible integration, and the second is the end-customer getting the data to work the way they want it. This is a win for Actian, a win for the Developer and a win for the End-Customer.