You’re offline. This is a read only version of the page.
Just getting into how our data gets into GP10 at the moment and trying to understand EConnect. As a basic question - If we provide a txt file to a directory folder is it EConnect that does the conversion from TXT to XML or would there be a another system in between.
1) Application TXT -> Network Folder -> System Converts TXT - XML -> EConnect Picks Up-> EConnect sends to GP
2) Application TXT -> Network Folder -> EConnect Picks UP ->EConnect Convert TXT - XML -> EConnect sends to GP.
Hey Ian,
I agree--SQL tables can add a lot of functionality that is helpful.
However, after doing a several SQL-based integrations, I ended up moving to a hybrid approach that combines CSV files and SQL.
Clients were looking for a way to import CSV source data files, but they needed complex data transformations, error logging, and the ability to reprocess data that failed to import. The challenge with a SQL-only option is that the tables aren't accessible to typical users, so although they could use a SmartList to view the data, they could not make any corrections to failed records or easily reprocess those records.
I developed an integration that uses the .NET SQL bulk copy operation to pull the CSV data files into a SQL staging table. I then transform, update, and prep that data for import. The data is then copied to an "import" table, where it is actually processed and sent to eConnect. The import table has additional fields, such as status flags, GP transaction numbers, error messages, etc. and gets updated during the import.
Rather than leave the data in the import table, I export the table contents back out to a new CSV file, to what I call an "import file". This file contains the additional status flag, doc numbers, error message, etc. The client is able to review the import file in Excel, review any errors, and if edits are required, they can directly edit and reprocess the file to import any records that failed. They are able to process and reprocess the import file as many times as desired.
This is the approach I developed for a client that had to process millions of records every week.
dynamicsgpland.blogspot.com/.../importing-725000-records-into-dynamics.html
To add to the other posts. Seriously consider importing your data into a SQL table - and integrating from there. This has some advantages. Once in a SQL table - you can write back to it once eConnect attempts a document. The attempt is either going to be a success or a fail - and you can send back different values depending on the result. You can also send back the error messages. You can then decide if you want eConnect to keep retrying failures or not. i.e. the failure could be because a GL account or something does not exist in GP....but it may get set up after the first try, and you may want eConnect to keep reattempting until it is successful.
Also, with the source data in a SQL table - you can add it to a smartlist. Users can run this smartlist filtered for failures - with the failure message detailed. After the first month of live integrations - 99% of the causes of failures will usually be on the GP side [a customer not set up, a financial period closed etc.] Using the smartlist a user can see why documents are failing and correct the problem in GP. This takes a lot of burden off the IT people.
Additionally using SQL tables [not hung up on SQL tables per se], you can script a transfer to a history table when documents are successful - so you have a full history of what was integrated.
This approach also means there is a barrier between the source system and the integration so you know what side an error is on. If you can get the source system to auto populate the SQL table with the data...all the better. I've been developing econnect integrations since version 7 and every time we learn something new. As to using other products built on econnect - well, maybe its just me, but I prefer to work in eConnect and have complete control over what happens.
Ian.
Thank you to you both for your input.
I found out that our file monitoring service has actually been coded to do the TXT to XML conversion before dropping the files to EConnect. That completes the puzzle as far as what does what to what.
We are installing GP2013 next week and starting to configure the new system, we are not upgrading but rather starting with a clean system due to historical documentation issues (on GP10 with customisations everywhere.)
I am looking at Smartconnect, Scribe and VKonnact as alternatives and also looking at how our feeder systems can be redesigned to provide better handling.
Hi,
The core of eConnect is a 'passive' API. It accepts data prepared in a specific format and inserts it into GP. Technically there are some other components that could process XML files, but I don't recommend them.
I like to say that eConnect only represents 20% of an integration. You have to develop the other 80% yourself, which includes data export, transformation, validation, and serialization (conversion to XML using an eConnect method) before you can submit the data to eConnect.
You would typically develop a .NET application that would locate and copy your source data (TXT) file, then read it, then validate it, then serialize it, and finally submit it to eConnect. You have to write your own error handling, logging, and optionally, email notification.
And if you are importing a 1,000 record file, and 75 records fail to import, you typically need to have a reasonable way of reprocessing those 75 records without re-importing the 925 that imported successfully.
I have developed several libraries over the years to do all of this, so when I create an eConnect integration, I'm putting together building blocks of code and wiring them all up to produce a complete integration. But if you are starting from scratch, you will want to give yourself plenty of time to handle all of these "supporting" processes.
If you are only doing a few integrations, or if you have very complex integrations, then developing your own may make sense. If you expect to need a dozen integrations from multiple systems to GP, then you may want to look into Scribe or SmartConnect. They require a larger initial investment, but in theory they can lower the marginal cost of subsequent integrations.
Hi,
By using eConnect, you must be able to create or consume eConnect XML documents.
To integrate your application with Microsoft Dynamics GP, eConnect requires you to submit XML documents that describe Microsoft Dynamics GP documents and transactions. To ensure the documents can be consistently processed, eConnect supplies a collection of XML schema that define the XML documents eConnect accepts.
By programming logic we can achieve the above two steps. the basic work flow as follows.
1) It reads the input file from the network folder
2) Process all the validations
3) Once the validations are over then it convert all the data to eConnect XML documents
4) Data get inserted into GP once the eConnect XML documents get ready.
Note: eConnect service needs to be run during the Integration process else Integration process get stopped
Stay up to date on forum activity by subscribing. You can also customize your in-app and email Notification settings across all subscriptions.
#1
André Arnaud de Cal...
290,522
Super User 2024 Season 2
#2
Martin Dráb
228,441
Most Valuable Professional
#3
nmaenpaa
101,148
Share
Report
All responses (
Answers (