RE: Common Object Management/Data Access Methods

["Mike savino" <mikejsavino@xxxxxxxxxxx>]

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