INTEGRATION OF ADDMEN SOFTWARE OUTPUT WITH OTHER SOFTWARE

Some users use the complete features of Addmen Software for their complete process from Sheet design to Generating and displaying results in various formats.

While some other users already have their Result Processing Software or Institute management Systems or MIS reporting softwares in place and their only need is to get quick and accurate data from the OMR sheet which they will import and process in their existing software to get the results in their preset formats.

In such a case the user makes use of the popular Addmen OMR reader tool only to read the data from OMR sheets and then use this data to perform their own calculations inside their software which they are already using.

Features for Facilitation of Data Integration

It is not necessary to goto the software Data Export interface, and export data manually, instead there are a few features to directly create an export file in the preset output format.
In the professional version the software can directly insert data into your existing SQL or Access Database.
It is possible to set the desired path and database name of your existing database into which the software will create its standard output table.
It is also possible to tap the data from open password less database built during the reading process.
With the use of Module PF (server integration) even the standard variant OMR readers can directly upload to designated SQL data server.

Data Export Interface after Reading an OMR Form

Sample Generic Output for Integration (Excel Format)

Sample Generic Output for Integration (DAT Format)

Basic Concept and Approach of Data Integration

It is important to understand the approach of integration.

For sake of simplicity, let us assume the software used in first part of the process to generate data is Addmen OMR Software so we will call it Software A.

And the software used in the second part of the process which will receive the data and do the calculations, is the client's software so we will call it Software B.

Both softwares A & B to be integrated have been developed by two different teams. None of the team knows the internal work process and data structure of the other software.

So both softwares will be obviously different in many ways, the way they store data and interpret data might be totally different. The Database is different, the table names are different, the fields name, structure and type all are different.

And this is a common scenario whenever there is a hand-shaking between any two softwares in any process. So there must be a universally standard and commonly acceptable way of approaching the integration.

Let us assume there are two softwares A & B, to be integrated such that data output generated by Software A (Addmen OMR Reader) is to be used by Software B (Client's Result Processing Software) as input.

Then such software hand shaking (data integration) can be done in two ways:

Pull Integration - Software A will provide a generic output which will be selectively used as input by Software B.
Push Integration - Software A will provide a specific output in the format required by software B.

What is the Ideal Approach for Data Integration?

Mostly clients who suggest Push Integration, are not aware of the challenges and implications of this method.

Since every Software B has its own database, secure logins and specific table and field structure, which Software A does not know. So Software A cannot put directly into software B unless all this information is known to the Software A.
Even if this information is shared, still since the information is specific to one specific software, then specific code will be required to insert data into the table structure of Software B. This specific provision is obviously a customization and involves cost.
Secondly, though the Software A is ideally calculating lot of information, but since the Software B is accepting only limited part for its use, then the other information is unused and getting lost. So whenever there is change in the work process or data structure of Software B, whenever they want to make use of more information, then every time the Software A team will have to be involved to make change in its code, which not only increases dependency but also becomes a costly affair.
Thirdly, Software A (Addmen OMR), is an independent product, it is not feasible to maintain a separate codes for each client. It is also not feasible to make the general product code complex and hefty by adding every users specific requirement. Neither a separate code for each user can be maintained, not all the user specific customizations can be overloaded because it is damaging to software efficiency. All these factors have time and cost associated with them.

The best approach for data integration is the Pull approach which eliminates any dependency, delay and any cost

Software A which is a independent product, will do its task in standard way.
It will provide all its data in generic and commonly aceptable format like Excel/Access/SQL/CSV/DAT/TXT/XML etc.
It will also provide proper explanation to each field of information in its output.
Integration will be done at the level of Software B team, considering Addmen product as Software A.

Then it is the choice of the software B to pick and use selective fields as and when needed, without dependency on Addmen OMR Software team.

Since the Software A (Addmen OMR) will not have to do any user specific customization and its task will be over in common way. So there is also no cost for such integration.