Dave,
Just to build on to Joe Pluta's remark:
"what you really need are hooks for incorporating all the
business rules down at the object level. Without that, such a wrapper
is roughly equivalent to a simple remote database connection."
We recently evaluated an Adapter for JD Edwards. We were hoping that it
would have all the hooks into the system but (as far as we could tell) it
ended up being just a message delivery system with the ability to access the
JDE Data Dictionary. In the end we decided to build our own adapter.
According to their early promotional literature, the adapter was supposed to
work in conjunction with either/or the JDE E-Commerce files or what is know
as the JDE Z-Files, which are just pre-defined batch interface files. Both
sets of files have corresponding applications with all the necessary hooks
to make sure that your production data base is properly updated -- enforcing
data integrity and business rules. Unfortunately our upcoming interface
project is for Item Master information and there is no pre-defined JDE
interface for our release of JDE. When we asked the vendor for a list of
all the pre-defined JDE interfaces that their adapter would work with
out-of-the-box, we never got an answer. Even if the vendor had a long list
of interfaces of this type, it would have required serious modifications on
our part. Since these are best suited for bulk-loading large volumes of
data in a Batch environment, there would be a lot of re-work involved
getting these to work with transactional data. Our Build vs Buy estimate
showed that about two-thirds of the effort required was in establishing
hooks into the production data. And if they are not included with a
purchased adapter, they'd need to be developed with every new transaction
type.
Joe's other point about Error Handling is also well taken. We were
disappointed to learn that the vendor had no error repsonse mechanism in
place. As a matter of fact, they had no way to close the loop on a
transaction, Period. Therefore, since we considered this a requirement, we
would have been stuck with the responsibility of extending their product to
do something that every interface should already be doing.
So my recomendation would be to ask a lot of questions and don't assume
anything. And if there's something about the answer that you don't
understand, get clarification. The vendor will almost always say "Yes" so
make sure you pin them down on the How, When, Why etc. Make up your own
list of requirements and then find out if the vendor's product satisfies
them all. If not, then that's work you'll have to do or pay someone else to
do for you. For example, we almost took it for granted that the adapter
would handle Query Inquires. When we asked the vendor they seemed to dance
around the question. We pressed the issue when we discovered they had no
response mechanism (what good is a query without a response?) and they
finally had to admit that the adapter couldn't handle Queries. Also, try to
get a Demo where You can define a typical real-life transaction, not
something that's faked up and over-simplistic.
Just a side note: Building an application to handle Outbound Transactions is
fairly straight forward. We've done that here and we're happy with the
results. It's the complexity of the Inbound Transaction that started us
looking for an off-the-shelf solution.
Mike
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact
[javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.