RE: Creating Custom Nodes for eConnect
Hi,
If you are a GP customer developing an import for internal use, or a GP partner developing an integration for a customer, I would not recommend using custom nodes with eConnect. If you are an ISV developing an API for developers that also commonly use eConnect, then maybe, just maybe, it might be worth the effort to use custom eConnect nodes.
If you are developing a .NET application that will serialize data and call eConnect, I see little reason or value to using custom eConnect nodes when there are much easier approaches. Just create a new method in your code that calls the database directly--via SQL statement or stored procedure. If you need transactional integrity, use a transaction in your .NET code that spans your eConnect call and custom calls.
Or if you want to keep the customization outside of .NET, use the eConnect Pre and Post procedures and use the User Defined fields on your eConnect transaction to pass in data to those procedures. That allows you to keep it all in SQL, in theory. You'll have to figure out how to handle errors in SQL and determine how errors should bubble up to your calling .NET code, but for smaller extensions of an eConnect import, Pre and Post are options.
If you are an ISV developing an API, then you could consider custom serialization, but you should weigh other options. Is the eConnect serialization + stored proc design so good that you should piggy back on it? Or could you develop an API that is simpler? Why not just develop a .NET assembly that can be added as a reference, with traditional objects and no serialization? Ask yourself: What value does serialization offer?
I've developed numerous integrations where custom data imports were required and have had no reason to explore custom serialization. For client projects, I can't justify the overhead of such a design and see little value in serialization for an integration that is running locally in the customer's GP environment.