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
- Framework EDI overcomes the problems of EDI
- An EDI Story
- Framework EDI methods and properties
- EDI Validation
