The topic of MFP platforms and the SDKs for writing to these platforms is gaining steam. Take a look at Alan Joch’s post today on the Print & Imaging Blog.
In Part 1 of our post on document imaging platforms for MFPs, we talked about some of the considerations that developers should consider when choosing a platform to write to when looking to integrate MFPs with software applications.
The biggest may be cross platform support. Developers should look for a document imaging platform that offers a single SDK that allows the development of a connector or document service that will work across any type or brand of scanning device – whether that is an MFP or a scanner. Even if your environment today only has one brand, taking a cross-platform approach will prevent problems that result from being locked into a specific brand or type of device and allow flexibility in office equipment purchasing decisions down the road.
There are also other advantages to a cross platform approach:
- A single SDK – eliminates the need to track changes to SDKs from multiple vendors that support different and limited capabilities
- Scanning Services – eliminates the need to learn how different MFPs and scanners scan documents, change scanner settings and handle scanning errors, etc. This is built into a cross-platform document imaging solution
- Administration – you can integrate any connection or document service into a single administration console that can be used for any MFP or scanner in a heterogeneous environment.
Whether you are a corporate developer or software vendor, the emergence of development platforms for MFPs are certainly worth looking into in order to help get paper-based information into software applications.
This would make life easier for software developers and organizations that have not yet standardized on a single MFP Vendor platform, but i think the task would be incredibly challenging. If you look at the vendors across the board, it is amazing how they differ in advancement on this front.
For the most part, it seems MFP vendors would rely on some type of middleware or "helper" application to facilitate the integration. I have found eCopy as the perfect tool, with great integration capabilities right out of the box. For instance, we placed several units at a growing city in California. Their plannning department wanted integration with their permitting software, and the quotes from development companies were crazy. With eCopy, we figured out the DB table structure of the permitting DB, and used a DB quick connect to write the metadata to the DB, and place the image in the appropriate directory. Problem solved.
ScanGuru
www.scanguru.com
Posted by: Steve | March 21, 2008 at 09:48 PM
Steve – Thanks for the comment. Yes, you are absolutely correct that a middleware application is the easiest way to facilitate the integration. And your customer example is a great use case for eCopy’s QuickConnect functionality. Using eCopy QuickConnect allows you to browse folder structures and send a scanned document to a folder (with or without metadata included), or scan directly to a database, eliminating the need for the database application to retrieve the document from an intermediate folder.
However, in cases where there is a business need to integrate directly with an application – allowing you to work in real time with the application from the scanning device – than using an available eCopy ShareScan connector -- or the ShareScan SDK to build a connector -- is the best approach for the same reasons that you cited: use a middleware (or document imaging platform) to facilitate the integration vs. using individual SDKs from the individual MFP manufacturers.
Additionally, our SDK allows developers to program to an application API (which are typically published and available from software vendors), without the need to know the underlying database structure. To put that in context, if the customer were familiar with the permitting software and its APIs, but not familiar with the database structure, the SDK would make more sense. Some applications obscure the database structure or simply have a structure that is very complex, in which case an API integration makes more sense.
Posted by: Tristam Wallace | March 28, 2008 at 12:52 PM
Hello!!It is my horour to see you blog.Iam agree with you,Ithink friendship is very important,so we must have a lot friend,History repeated proof: friend, health than leadership than performance than IQ, eq, holiday greetings than usual, as an important than. Space than the ground is good, to visit friends, no tickets. If you want to buy a shoes, Please come here Nike Air Max 90.
http://www.buynikeairmax90.com
http://www.uggbootstore.org
http://www.uggbootsvv.com
Posted by: Nike Air Max 90 | December 16, 2010 at 02:31 AM
I agree with Steve as well. I Like how they moving forward with a lot of the software but should make it more user friendly to be ab le to move files between software.
Posted by: Imaging Platform | January 19, 2012 at 01:14 PM