RE: Common Object Management/Data Access Methods -- MIDRANGE-L

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