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.