EDIdEv - Electronic Data Interchange Development

What is Framework EDI?

Q.  I'm not a Windows programmer, so can you give me a definition of the Framework EDI component in layman's term?

A.  For simplicity sake, the Framework EDI component can be compared to as a full fledge EDI application that has all the functionalities for translating, generating, acknowledging and transmitting EDI files - but that it does not have a user interface:  it does not have fields for entering data; it does not have a button to start a process; nor does it have a screen to display information.  However, it has connections to allow a programmer to connect a user interface onto it.  It is basically an EDI Engine.  So that data entered from a field can be passed to it,  a button clicked on a screen can call it to start a process; and that data can be retrieved from it to display information.  As an analogy, we can compare the Framework EDI component to an engine of a car, which has connections on it, to allow a car maker to connect parts like the accelerator pedal, gear box, and all other car parts that can be built around the engine so as to make a car of his own design.

Q.  Do you have to be a programmer to use Framework EDI?
A.  Yes, to fully utilize Framework EDI, one would have to be a programmer.  But the skill requirement, and the work load of the programmer is reduced dramatically.  For example, programmers no longer have to spend time writing source code to ensure that their EDI file format is correct, because the Framework EDI component handles the task automatically.  Programmers can then spend more of their programming time on the business logic, and on niceties of their application.

Q.  How much EDI knowledge is required to use Framework EDI?
A.  The Framework EDI component hides and manages the nitty-gritty aspects of EDI so that even a programmer with basic EDI knowledge can use Framework EDI immediately.  It also acts like a guide by restricting actions that could create an invalid file format; and it is therefore also an 'on the job' EDI training tool for programmers.
     A common myth states that "EDI is difficult".  But in reality, EDI is only difficult if one does not have the correct tools.

Q.  Do you provide or sell the source code of the Framework EDI component?  Because what if it doesn't exactly do the function we want it to do, can we modify the component to fit our needs?
A.  No, we do not provide or sell the source code of the Framework EDI component.  The advantage of working with components is that they are used at the programming level, which means that a programmer can add source code around the component to add to its functionality to meet a unique task in a business process.  Similarly, with FREDI-COM or FREDI-NET, the programmer does not change the actual component, but basically adds code to work with it to come up with a new function.  This flexibility and control does not exist with 'on the shelf' applications.  If source code is not available with an application, then a change in a business process can deem an application obsolete. 
     Components are basically locked-down function source codes that are safe from being modified.  And the Framework EDI component is just that, it provides to programmers, common programming functions that have been well tested for EDI processing and transmission.

Q.  With so much control given to programmers to create an EDI file, could the integrity of an EDI file format be questionable?
A.  EDI files are like any other computer files, which can be created by programmers using any programming language.  If a programmer is not given a tool specific for creating EDI files, then the chances of creating an incorrect EDI format is high.  The Framework EDI component is a tool specific for EDI files, and therefore significantly reduces the possibility of a programmer incorrectly processing EDI files.

Q.  Our company only needs to generate EDI files, and don't need the other functions that Framework EDI provides.  So we are thinking of writing our own EDI functions to generate EDI files instead of using your component.
A.  It all depends on how much time and money you want to invest; and how much trial-and-error you can accept.  Small projects always turn out to become big ones.  When a company starts to use EDI, it may begin with having only one file form, but undoubtedly it will progress to have many file forms of different versions, which would continually change.  To write source code to incorporate the many varying messages requires considerable time and EDI knowledge - an ominous task, which only takes away time that could be used for writing code to support the business aspects of a company.
     Also, some companies make the mistake of believing they would only need one process in their EDI transaction e.g. generate files only.  But in reality, because EDI is the exchange of files, a company would sooner or later have to put in place the four basic processes of EDI to have a successful automated file exchange, which are: creating, translating, acknowledging and transmitting EDI files.  These four processes are easily managed by the Framework EDI component.

...more frequently asked questions.


    Click here to evaluate the Framework EDI     


Other Topics