Looking for EDI component

I'm looking for an EDI component that's comparable to edidev's www.edidev.com, but is native to VB.NET and also works with java.

Welcome to the forum!

That link you gave came up dead - is it not up?

What are you trying to do with the EDI file from VB?

Thanks szlamany!

I'm just shopping around for all options out there to easily read and generate EDI files in .NET or java.

I've only ever done EDI with translator applications that output flat text files for import/export with VB.

Was that link to a set of functions that allow you to do this within VB?

What EDI standards are you working with? What type of industry?

I actually prefer to manage the EDI file as objects (and not have to parse a flat file.) I like how the edidev component works because it's generic and not specific to an industry, unfortunately it is not native to .NET and does not work with java. There are ways around to use the component with these languages, but if there's another component (that's comparable to edidev) that is native to .NET and/or work with Java, then I would prefer to use that.

I just visited the edidev website, so it is up. I don't know why the link is broken for you.

We're starting with the X12 810, 850 and UN/EDIFACT INVOIC, but we'll have other projects in healthcare HIPAA 837 and 835.

Anyone have an answer to this question? I'm also looking to create a HIPAA X12 270/271 Transaction.

the nice thing about EDI files... they are flat text files...(nevermind, I see that you know this :P ) so by and large they are pretty easy to work with...(I think the files them selves are easy enough... it's usually the business logic at both ends where things go into the dumper) I'm not sure what you mean by a component that "is native to VB.NET and also works with java." as generally speaking it';s going to be one or the other... unless there's a way for Java to call .NET components... or the other way around... and there very well maybe... I'm just not aware of it.

so, are you looking for a full-blown EDI system (which is what edidev seems to look like) or a programmable set of objects that you can use to read/manipulate/write EDI files with?

-tg

@tg - 5 year old thread here - ems9tech just hopped onto it.

Welcome to the forum btw!

I see the link that the OP put up 5 years ago is up and talks about .net answers.

What are you trying to do?

Are you creating a translation tool? Or do you need to work with these edi formats?

Ugh... thanks for that... didn't even notice... grrr...

-tg

Sorry, if you want I'll start my own thread. Basically, I am looking for a free "programmable set of objects that you can use to read/manipulate/write EDI files with"...in .NET I also saw the EDIDEV component and stumbled into this thread. From the sounds of it, I'll be writing my own code from the ground up, but with all of the loops, etc., thought it might have already been turned into a reusable component. I could use the EDIDEV concept and attempt to build a class (or DLL) to emulate some of it's reusable functionality... :~(

I've always written my own edi code - loops and all.

Seems you never really have a full set of output to fill the standard anyway. Or maybe you will in your application.

And when I'm getting edi files in they usually only fill the fields they happen to have on there end.

Same here... problem with EDI is that a lot of it is up to the parties to agree on what they will or will not have... and often it jsut simply says "you will supply a value indicating X" .... but then how you represent X is never specified, so you get one source that uses 24, another that uses "x" another that uses "X" and there will be the one rogue that uses "equis" sigh... I did my battle with X12 from a financial side, we had three sources, all in the same state, same industry, all using the same state mandated X12 standard.... and we got no less than 5 different formats from there. And then we had to write files back...

-tg

I always preferred to have full control over EDI in code. Why would I need an object model to replicate\cover that and have endless types for all EDI messages ?!?
We used edifabric to provide a robust framework for EDI to XML translation.
All EDI messages are converted into XmlDocument - that is the ONLY object model I need. Every application understands XML and nowadays, with Linq to XML it's even easier and faster to manipulate it.
It's not a random XML - all schemas are shipped with the framework and every message XML representation conforms to a schema.
All conversion adheres to a contract.
All EDI is converted to XmlDocument.
That is the future.

When I manipulate EDI in code I would prefer to have the following:

1. Interface\contract
Whatever the EDI is going to be converted to, needs to be predictable for all clients\users.
2. Natural object model
Why would I want to convert EDI to a custom object model ? Then share it with someone, who needs to learn it in order to use it. How extensive and elaborate could that be - supporting thousands of EDI formats and dialects ?
This is a lost cause. What solves my problem is XML. Convert EDI to XML - the perfect object model - it represents hierarchies, is extensible, is platform independent and virtually everyone understands it.
It also solves the contract requirement - all I need to support an EDI format or dialect is to have a Xml schema, which describes it. Voila!
3. Easy to plug in framework
I've used edifabric to do all this for me. It's got a WCF web service, which I called from Java. No hassle, no issue. The performance is sufficient as well.

Generally I don't like edidev approach to proprietary object models. Who would actually ? Bringing yet another representation\format forward is the easiest for the implementator, but not for the customer\consumer.
And there is XML with a standard ISO format for describing EDI, why even think of something else...

Welcome to the forum!

This thread is over 5 years old - seems silly to bring it back to the surface!

Do you have a question?

DonZ - that's all fine and perfect... in a perfect world... however... at the time I was dealing with EDI it was in VB6... and was close to 5 years ago... so I didn't have the luxury of Linq... heck, I didn't even have the luxury of .NET... just a crummy VB6 object model I inherited. We did the best we could under the circumstances. Also, we were trying to implement something that our system could interface with any given EDI document... at the time we were consuming a huge amount of EDI document flavors... probably something around 36 or so... and we had custom import objects for each of those types, for each vendor for each client! ... it was a mess, we were trying to consolidate it down to a single object model that we could drop into the plugin folder of any of our clients. then all they have to do it point it at an EDI document, it would read the header, determine what it was dealing with and populate the object model... then from there it could either construct an XML document that could be sent to a third party vendor, or it could be consumed by the system itself. Then we had to reverse the data flow... writing out the EDI document based on XML from the third party vendor and/or from data in the system.

tools/frameworks today are great, but even as recent as 5 years ago... trying to find something to fit into our system... just wasn't happening.

-tg

I have to second some of the comments above.

Not only do the other partners generate and consume a subset of "the possible" you often only care about and can generate based on the subset that you need and have as well. One of the big headaches is mapping data between a given "EDI standard" and you own internal needs. This can even happen on something as seemingly binary as gender: the standard might support male, female, and unknown while you and other partners might internally support differing alternatives (formermale, formerfemale).

Don't laugh, it's true.

Not to mention larger items that might be buried in the standard's data model.

Even using a big name programmable data broker product we ended up writing a ton of custom mapping logic.

I believe it... the barrier we ran into was that more often than not the EDI spec simply say you have to have "X" .... but how you implement "X" is up to you... it jsut has to fit in the space provided.

-tg