Creating Custom Nodes for eConnect

(0) Share

Report

Posted on by Community Member Microsoft Employee

I am currently working on a eConnect project that requires custom xml nodes. I read Dave Musgrave's blog about creating a custom serialization and see that he uses xsd.exe to build a new class based on a xsd document that he modified from the eConnect 12.0\XML Sample Documents\Incoming XSD Individual Schemas. I want to know it this is the only way to do it. Is there a way to modify the xsd documents that eConnect is using without having to create a new class? Also, will adding the custom node to the XML call the custom stored procedure without serializing it if I don't want to create a custom serialization?

*This post is locked for comments

All responses (3)

Answers (0)

Community Member Microsoft Employee on at

Like (0)

Report

RE: Creating Custom Nodes for eConnect

Hey Derek - The answer to your question is that you can bypass serialization but stay consistent with the architecture and nest your calls appropriately through eConnect. The value of eConnect is nesting your nodes together and not dealing with all the transaction stuff. If you do not need to integrate with other eConnect nodes than you can easily choose whatever option you like. The other value with eConnect is using a code generator to get the base sql objects developed for you. A product like ezCinect, www.plainsmobile.com, can auto generate your base object logic for you so you can focus on the specific business logic required for your integration. Also ezCinect, can automatically handle your custom objects as well without dealing with serialization and other development challenges. There is a demo on the site which walks through one of the integration methods you can use. Basically, ezCinect provides a much more supportable integration environment with an easy way to extend functionality with new nodes as well as overall architecture to manage exceptions while providing an audit control mechanism. The product is also integrated right into GP so the install only takes minutes.
L Vail 65,271 on at

Like (0)

Report

RE: Creating Custom Nodes for eConnect

Steve,

Nice answer.

Leslie
steveendow 2,281 on at

Like (0)

Report

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.