Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Creating an Electronic Data Interchange System?

Cliff posted more than 9 years ago | from the electronic-dialog-implementation dept.

Communications 47

jgrumbles asks: "I've been in a PC support technician internship for the past 7 months for a polyethylene (plastic) pipe company which has doubled in size the past 4 years. I've been notified that management wants me to head a new initiative within the company. The main goal, in the beginning, is to basically restructure the slipshod EDI system they are using right now. The IT director even admits he should have had some training when implementing the system, but it was at the time of the boom so he had to do it as he went along. Are there any definitive EDI/E-Commerce information conglomerates, websites, listservs, groups, or other sources of information? My main mission will be to recreate the EDI system, which includes an AS/400 in a Windows environment, from scratch. Further down the road I'll be in charge of implementing technology in other areas such as getting RFIDs on every piece of pipe we ship in order to further automate tracking and billing. So, does anyone have suggestions on where to look for information and possible case studies?"

Sorry! There are no comments related to the filter you selected.

I can see the memo now. (4, Funny)

grub (11606) | more than 9 years ago | (#13579137)

Boss: jgrumbles, our company is growing fast; we've doubled in size over the past 48 months. We need you to design, build and implement an EDI to replace our AS/400 system. Plan for expansion into RFID, shipping and automated tracking & billing. Would you mind using Ask Slashdot for guidance in this risky, company-wide endeavour?

Hey (1)

PunkOfLinux (870955) | more than 9 years ago | (#13579148)

Do you really need RFID that badly? It's pipe, for god's sake
What the HELL are you talking about? Like, stuff used to control machines or what?

Re:Hey (1)

/dev/trash (182850) | more than 9 years ago | (#13581899)

It's still a tangible good. Does Walmart need RFID on ALL that toilet paper?

Google and OLD IRON (1)

Marxist Hacker 42 (638312) | more than 9 years ago | (#13579173)

Ok, this REALLY should have been one for google- even I admit that and I'm usually on the other side. Just how many hackers on slashdot do you think have even messed with EDI?

Still, given IBM's movement to bladeservers, I'd suggest whatever solution you come up with should eliminate the maintenance cost of the old iron, the AS/400. You'll save enough money there alone to purchase a fleet of blades, and even if you're running Oracle or MySQL, you're better off than DB2 on a single mainframe.

Re:Google and OLD IRON (2, Informative)

llefler (184847) | more than 9 years ago | (#13579484)

Ok, this REALLY should have been one for google- even I admit that and I'm usually on the other side. Just how many hackers on slashdot do you think have even messed with EDI?

There are a few of us. Actually probably quite a lot of us.

Still, given IBM's movement to bladeservers,

Obviously you haven't, EDI is not about hardware. You should have googled too.... [] would be a good place to start.

Simply put, EDI is a set off transactions for communicating B2B. (Business to Business) Electronic orders, invoices, advanced ship notices (ASN), electronic Bills of Lading. They are flat text files with tokens (slashdotters will love that, it sounds like a config file).

Then of course there is XML EDI.

Re:Google and OLD IRON (1)

Marxist Hacker 42 (638312) | more than 9 years ago | (#13579947)

The point is- both of which can be done better WITHOUT an AS/400 in the mix. It's drop dead simple to go from SQL to whatever flat text file format you want- and XML is still a flat text file format.

Re:Google and OLD IRON (3, Insightful)

Mr.Sharpy (472377) | more than 9 years ago | (#13580620)

The point is- both of which can be done better WITHOUT an AS/400 in the mix. It's drop dead simple to go from SQL to whatever flat text file format you want- and XML is still a flat text file format.

Riiiight. This really cements my opinion that you DKWTFYTA. If they're using an AS/400 for their EDI now it probably means that it's also doing their ERP, invoicing, and other accounting. Doing away with their AS/400 would most likely mean even wider changes in their organization than just changing edi platforms. You can never simply "dump your as400." Were you even aware you can work with your DB2 UDB on your MIDRANGE (NOT A FUCKING MAINFRAME) iSeries with vanilla SQL?

Besides, you can create all the x12 text files you want, but if you're dealing with a lot of customers or vendors you're probably going to need to go through a VAN in which case you'll want their EDI suite anyway.

And going back to your original post, have you ever even worked on an iSeries (as400)? Long after all your blade servers have died strange and varied deaths, that iSeries will be chugging in the back room. I don't think you'll ever find a system as stable and well documented as the iSeries.

When it comes to business continuity you can't put a price tag on it. I'd MUCH rather pay a shit load of money for an iSeries that will run without complaint for decades with little intervention, than a slightly lesser shit load of money for a raft of pc blade servers.

Re:Google and OLD IRON (1)

the morgawr (670303) | more than 9 years ago | (#13584952)

We've used that product line for almost 15 years now (we started with the predecessor, the system 36, and upgraded to the 400 later). We've never had a single hardware problem. The computer runs 24/7/365 without a single glitch. It's expensive, but it does work.

Re:Google and OLD IRON (1)

bpfinn (557273) | more than 9 years ago | (#13608246)

This really cements my opinion that you DKWTFYTA

You must know what you're talking about. That looks like an OS/400 command to me. :)

Re:Google and OLD IRON (2, Informative)

llefler (184847) | more than 9 years ago | (#13582930)

No, the point is that it's not a hardware issue. It can be done on AS/400, it can be done on VMS, it can be done on windows, and I would assume that it can be done on Linux.

It's like someone asking you how to do a mail merge, and you telling them to rip out MSOffice and Windows and install Linux and OpenOffice.

And no, it's not 'drop dead simple' to go from SQL to x12 EDI. Because there are going to be a lot of business rules in there. Most EDI is legacy, and companies are not using XML yet.

Re:Google and OLD IRON (2, Insightful)

Marxist Hacker 42 (638312) | more than 9 years ago | (#13584390)

Ok, in this discussion I've learned that what I thought was an old mainframe is really a minicomputer. And that grid computing isn't as useful as I thought it was for getting rid of an IT department. And yes, I used to consider ANY opportunity to rip out legacy hardware and software and replace it with something more maintainable a good thing, thank you for correcting me.

But tell me, why are other programmers so scared of a well defined set of business rules, no matter how large it is? A data transform is a data transform, and while it may take you some TIME to code a data transform, and testing to get it correct, it's a heck of a lot simpler than say, coming up with a new algorithym to break the latest DRM attempt from the RIAA. At least you HAVE business rules. Anything that has business rules to transform one set of data to another is easy money, as far as I'm concerned.

Re:Google and OLD IRON (1)

llefler (184847) | more than 9 years ago | (#13585647)

Ok, in this discussion I've learned that what I thought was an old mainframe is really a minicomputer.

To our users, our Alpha VMS machine is still the 'mainframe'. Even though we probably have laptops with more computing power. And our SQL server leaves it in the dust all the way around (memory, CPU, storage). IMO, mainframe has become more about the experience. They don't know the difference, so why confuse them. Just as long as we know.

As far as ripping out legacy, it comes back to 'if it works...' You see an AS/400 as legacy. Someone else might see Netware as legacy, although NDS is just as powerful as ActiveDirectory. Running a windows network without AD? Come out of the dark ages. It would be very easy to churn away your entire budget killing the legacy beast. Fortunately, most businesses won't allocate the money unless there is a measurable benefit to the business. If you're not a technology company, your customers don't care about the shiny kit in your computer room.

But tell me, why are other programmers so scared of a well defined set of business rules, no matter how large it is?

Because rarely are the business rules 'well defined'. Assuming they have ever been written down, the process has probably been changed several times since the documentation has. Recreating the process means reading the documentation, analyzing the existing code, and talking to the stakeholders. You'll probably end up with three different 'rules', and all of them might be wrong.

But lets say you want tackle it anyway, and you get the $$ allocated. If the stakeholders don't currently see the process as broken, your best result is going to be it does the same thing the old system did. Sure, it might be faster, have new features, and be extendable. But they weren't asking for that. The risks OTOH are that you could break it, your new system might not work or not work right.

Most of us have plenty of other work to do without tackling projects no one wants. That means when you need to add non-core functionality, like EDI, changing the existing system isn't your first choice. Can you buy a package the integrates with your current system? Can you buy a package that bolts on the outside? Can you write mods for the current system? Can you write a package that will bolt on to the current system?

Eliminating Legacy, the primary business reason (1)

Marxist Hacker 42 (638312) | more than 9 years ago | (#13591418)

The Business Reason for getting rid of legacy is to cut down on maintenance cost going forward. Sure, the old stuff still works; but as time goes on you'll find fewer and fewer programmers who want to work with it, or even have the faintest clue how it operates, because it was primarily written under the "find a job niche and protect it" school of design. What we're now finding out is that software and hardware, even the cheapest software and hardware, can be in use for decades. Thus, the good CIO will, when given the opportunity, redesign the entire system so that it is easily maintainable and extensible. So that, as you put it, new packages can be "bolted" into the system quickly and easily.

As for the complexity of the business rules, EDI has got to have the simplest set of business rules ever created. You have this well defined database on one side; well defined because of the meta data in the database, you know the data type and format of every field to start with. You have this well defined interface form on the other side, well defined because the standards organizations make it so. That's internal to your own IT department. Now you meet with the IT department from the business you want to send the data to. They've got their own well defined database format, but you don't have to know anything about that. All you have to do is come to an agreement of what standard form to use, and how to ship the data. From there on out the programming is a complete cake walk. You don't actually have to invent anything at all; in fact, asking other stakeholders for input is a really bad idea because they'll just insert a bunch of stuff that isn't needed into the standard.

The hardware and software that you do this with doesn't really matter as long as Database A puts out a report in format B that Database C can read and store. Yes, there may be thousands of columns per record in that report- but string manipulation is the easiest programming possible no matter what system you're using, or what programming language for that matter. And that's all data transformations are- string manipulation.

Don't get me wrong- I understand what you're saying about non-computer people not allowing you to do your job properly, we've all been there. But the closest the business should *ever* be allowed to get to the desgin of an EDI project is telling the CIO "We need to be able to send records from this system to this other company, make it happen", and from there on out, it should all be negotiation between IT departments, not lusers.

Re:Eliminating Legacy, the primary business reason (1)

llefler (184847) | more than 9 years ago | (#13593436)

As for the complexity of the business rules, EDI has got to have the simplest set of business rules ever created.

Well, I'm not going to argue with you. I work and consult with the programmers who write the code for our EDI every day. We are in the middle of a migration from an VMS system to Axapta, so all of our EDI work is being redone. Despite the fact that we use Gentran for the actual packaging and transmission.

Here are some examples that you might run into: a 210 for Yellow Freight may not work as a 210 for USF. You can properly format an 810 (invoice), but still have it kick out of your customer's system. Which means you don't get paid. Does your customer want your part number on the 810 or their own? Some customers are going to send an 850 (PO) and 830(s), some will just send an 850. BTW, an 830 can change order qtys and ship dates. One very important business rule cannot be part of a canned EDI system, what is the freeze period on order changes. Again, your part number or your customers? Each individual customer decides if they want 862s (ship schedule) and 856s (ASN). Does the customer require their ASN to be sorted by po/line item, part number, or container id? Do they just require equipment numbers or container details? Does your customer require consolidated shipments or must they be kept separate?

You can write your EDI 100%, to the spec, but if it kicks out of GM's system it's worthless. You fix it to match their system or you don't do business with them. The realities of business are; you can tell your vendors they aren't following the specs, but the customers' system is never wrong, it's your reference platform.

BTW, using the term lusers shows you have little respect for the people who you are paid to support. You have missed the whole point of your job.

Re:Eliminating Legacy, the primary business reason (1)

Marxist Hacker 42 (638312) | more than 9 years ago | (#13595219)

Yes, the customer's system is the reference- so why are you trying to write it so that two different customers are treated the same (despite the standards and specs?) You should have a different subroutine for each customer system you're dealing with, and whenever you get a new customer they should get a new module in the system. The primary message queue should simply be able to look at the customer id field, the form number, and use that as a primary key to call up the proper subroutine for that customer.

Black Box Archetecture is key; that's why the legacy code stops working, and why it's so hard to maintain. If you had gone with a black box archetecture to begin with, then it's a simple matter of setting up a meeting with the customer's IT department to find out exactly what format they want the invoice in- and everything goes smooth as silk. If you need to because of the large number of customers, hire a separate programmer for EACH customer. After all, the guy writing the black box to plug in to the system only needs to know his own inputs and outputs, not the entire system.

And luser is not a term of disrespect any more than lvalue is- do you disrespect the variables that end up holding the data at the end of a transaction? "Left user", not "loser".

Re:Eliminating Legacy, the primary business reason (0)

Anonymous Coward | more than 9 years ago | (#13598873)

Dude, I could post a huge list of problems that we run into when we implement edi with a customer, but you will never understand. Until you do an edi implementation with a big customer you do not know shit.

I would be interested to know how that meeting of yours turns out . . . lol. You will be lucky to get new test documents from an existing customer much less a real human to talk to.

Re:Google and OLD IRON (1)

luckystuff (836232) | more than 9 years ago | (#13613350)

"...and while it may take you some TIME to code a data transform, and testing to get it correct, it's a heck of a lot simpler than say, coming up with a new algorithym to break the latest DRM attempt from the RIAA. At least you HAVE business rules. Anything that has business rules to transform one set of data to another is easy money, as far as I'm concerned."

Value added.
Time = money. Time for testing, time for programming = more money. All to get a transform that is doing about the same thing that you're already doing on old iron? Run the numbers.
"Easy money" ? When your boss figures out that you're wasting time and accomplishing nothing, then 'easy money' => 'involuntary job seeker.' And yes, you can check the math.

Re:Google and OLD IRON (2, Informative)

Skalizar (676291) | more than 9 years ago | (#13579487)

The AS/400 is hardly old, although its possible his machine is. It's still being upgraded and improved, and one AS/400 (iSeries or i5 these days) can do the job of a rack full of blade servers. And while its doing that its far more reliable and was built from the ground up to handle databases. It NEVER crashes unless something is physically broken, and even that is rare since it usually detects hardware problems before they become critical. It handles our EDI just fine, although if you go with the industry standard Harbinger/Peregrin/whatever-they-call-themselves-t hese-days EDI software, it will be expensive due to the tiered pricing scheme.

For a good read on IBM iSeries, check out nds/index_flat.html [] .
A Slashdot "Hacker" who not only "messes" with EDI and the AS/400, but PLCs, industrial automation and RFID tags as well...

Re:Google and OLD IRON (1)

pjbus (728439) | more than 9 years ago | (#13579511)

The cost of replacing the "OLD IRON" AS/400 is likely to be much higher than simply purchasing a group of new servers to run new applications on. Most companies that rely on AS/400, iSeries, or i5 systems have a significant investment in the application software (whether custom or vendor provided) that actually runs their business. Plus, the question here was to build a way to get data in & out of the AS/400 to and from customers and vendors, not replace the application functions. Not sure if you realize it but there's nothing "OLD IRON" about the AS/400, it's currently known as the i5 and is a very viable platform. Thousands of companies rely on it 24x7x365 to actually run their business as opposed to justifying a large IT department.

Re:Google and OLD IRON (1)

dtfinch (661405) | more than 9 years ago | (#13580264)

If you've ever thought of selling to WalMart, you've at least looked at EDI.

Re:Google and OLD IRON (0)

Anonymous Coward | more than 9 years ago | (#13597357)

You are a no talent hack. Looking over your other posts on slashdot I see that you are a loud-mouthed know-it-all with absolutely no insight to add to any conversation. You should really just keep your fat lips shut and avoid any further embarassment on these forums.

Why? (2, Insightful)

bherman (531936) | more than 9 years ago | (#13579380)

Why do most people insist on recreating the wheel. I cannot imagine that your company needs some specialized version of EDI that no other company uses since that is the point of EDI (to make everything equal).

Tell your boss that buying standard software is usually cheaper than programming and supporting custom software to do the same job. Are you going to be writing the companies word processing software next. If so, quit now!

Try here []

Re:Why? (2, Informative)

llefler (184847) | more than 9 years ago | (#13579692)

Or, they could install a cheap Intel server and run something like Gentran [] to handle the actual EDI. This lets you map EDI data to file formats that your existing software can import/export.

Regardless, unless you find a package that handles EDI and communicates directly to the software you already run (which is rare), there is still going to be time required to learn how to create the proper maps. And if you deal with any large companies, you will find that many use their own 'flavor' of certain datasets.

Re:Why? (1)

rah1420 (234198) | more than 9 years ago | (#13582557)

Gentran is a bulletproof platform, but pricey. I work on the MVS version of Gentran now, and know the Unix version too.

Softshare Delta [] is raved about a lot, and it's relatively cheap.

Cheaper than Gentran, anyway. :) If you need to hang a box on the network for EDI, you probably couldn't do it any cheaper than Softshare.

Re:Why? (1)

clinton.greer (845218) | more than 9 years ago | (#13587792)

I support a Gentran installation for a large retailer. We process over 100MB of outbound traffic daily and Gentran probably drops it's bundle once a week. Data managers terminate without request, files fail transmission for no reason.
For high-volume concurrent processing of EDI documents it doesn't do too badly. Then again, it doesn't do too good either...

Re:Why? (1)

rah1420 (234198) | more than 9 years ago | (#13587840)

"data managers" - you're on the 'nix version; which one?

We process over 250MB daily (a Fortune 50 company) in our MVS version and I can't remember the last time we lost a bundle of data.

RFID on *every* piece of pipe? (1)

gothzilla (676407) | more than 9 years ago | (#13579408)

That is just overkill. The big boys have been messing with RFID and say that chances are they'll never RFID every single item. It's practical when marking containers and boxes but not on individual items.
Second, EDI is something very few people ever mess with because there are too many companies out there that can handle it for you. The trucking company I work with does EDI with some of our larger customers and it's completely automated and tied into our dispatching software. A company called TSi handles the transactions for us.
Don't re-invent what's already been invented. I'm betting whatever software your company uses for accounting already has a module that handles EDI.

Ask Slashdot: Do it yourself brain surgery? (0, Troll)

Neil Blender (555885) | more than 9 years ago | (#13579542)

Hello, Slashdot. I have a brain tumor and have decided that instead of going to a hospital, I'd try to operate on myself. I have the surgery part all worked out. I figure a hammer blow to my head and steak knife sterilize with hot water from the sink will do the trick. My question to Slashdot is two-fold: A. What open source life support systems are out there? and 2. Am I retarded?

Re:Ask Slashdot: Do it yourself brain surgery? (2, Funny)

Samus (1382) | more than 9 years ago | (#13579843)

1. I recommend GNU/Life. The current stable version is lacking some critical features so definitely go with the latest unstable version from CVS. I'd stay away from OpenLifeSupport and its KDE and Gnome counterparts. They seem to still be in their infancy.

2. No, I don't think so. You might want to perform your surgery at the local LUG's next install fest. That way you can get lots of support.

I have but one piece of advice... (0)

Anonymous Coward | more than 9 years ago | (#13579849)

..stay the fuck away from XML.

Develop Exit Strategy Now (2, Insightful)

Bravo_Two_Zero (516479) | more than 9 years ago | (#13580046)

No, seriously. That's a sure sign that your employer is, in a word, without sense or direction. Sure, there's opportunity in chaos, but my 15 years in IT haven't prepared me to take on a challenge like that.

We do EDI. We do it big. It's complex. It's a pain. Hire consultants. They'll waste your money, but it's not the sort of place into which one hops with no experience. Heck, hire a vendor like (Covast|Mercator|Gentran|Amtrix) to do it end-to-end. You'd be much better off career-wise learning to track and manage a project like that rather than to do it yourself.

(We're not consultants, by the way. We're a distribution company.)

Re:Develop Exit Strategy Now (2, Informative)

Linux_ho (205887) | more than 9 years ago | (#13580195)

Seconded. EDI isn't something you can just jump into with no experience in the subject. Not without royally pissing off your business partners, anyway. Also check out a company called ICC: [] They are pretty good. The service they offer is most valuable in that they use internet standard protocols for data communication, dropping costs and sidestepping most of the big VANs which still charge exorbitant per-bit rates for data transfer. I'd contact ICC, confirm that your business partners are willing and able to communicate via their network, then ask ICC for recommendations on implementation consultants in your area.

Re:Develop Exit Strategy Now (1)

jbarr (2233) | more than 9 years ago | (#13582338)

I agree. In the 12+ years I've been working on and off with EDI, I can say that it certainly is a pain, it can be cumbersome, and complex, but in some industries, it is essential. This is not a task I recommend tackling solo. Hire consultants and work with the experts. Expect to spend a lot, and expect headaches.

Just remember that EDI is not the system but a component in a larger process. Don't confuse EDI with the business process. You need to establish business policies and practices that incorporate ERP, EDI, warehouse management, and a host of other things.

Re:Develop Exit Strategy Now (1)

rah1420 (234198) | more than 9 years ago | (#13582575)

I can second this. You MUST have your business processes in order, or EDI will just transmit your crap to your trading partner.

And they will NOT like you. "Cost recovery" is the euphemism they use for charging you for correcting your EDI fuckups.

Ambitious! (0)

Anonymous Coward | more than 9 years ago | (#13581332)

Holy [bleep]!

You're an intern PC Support Technician which is to say you're learning how to work a help desk, and you've been asked to lead a team in designing, building and deploying an EDI solution which typically runs on mainframes?

What's next? Is your company gonna ask the guy who changes lightbulbs to step up to the chaulkboard and sketch out the full specs for powering and cooling a 512 node beowulf cluster?

Something really smells here...

Slashdot (1)

pete-classic (75983) | more than 9 years ago | (#13581536)

polyethylene (plastic)

You seem to have mistaken us for the airheads you meet at cocktail parties.

Maybe I'm just mad because I can never adequately explain what I do for a living to the airheads I meet at cocktail parties.


Re:Slashdot (0)

Anonymous Coward | more than 9 years ago | (#13617425)

Polyethylene pipe companies would easily do EDI for credit card transactions. Speaking of which the banking business, in my opinion, does the most real-time EDI of anyone. (Although [] might disagree with me...) So don't knock any-company-who-wants-money's aspirations for EDI, please. A.C.

No offense, but... (1, Insightful)

Anonymous Coward | more than 9 years ago | (#13581819)

I've been in a PC support technician internship for the past 7 months for a polyethylene (plastic) pipe company which has doubled in size the past 4 years. I've been notified that management wants me to head a new initiative within the company.

This is where you step up and tell your Supervisor, IT Director, or the President that you're utterly unqualified for this task.

Unless you're some whiz experienced systems analyst with experience in EDI and supply chain that could only get a job as a PC Support Tech, you're in WAY over your head.

It's not a jab at you, I'm not looking down at you, but this isn't a simple problem and tends to be rather mission critical.

If the company wants you involved in this project, they should find a consultant to organize and lead it and have him hand off leg work to you.

Best of luck to you!

Re:No offense, but... (1)

rah1420 (234198) | more than 9 years ago | (#13582595)

And actually, once things are humming, you can assume the day-to-day and have some relatively recession-proof skillset.

AS LONG as you remember the primary caveat enumerated earlier; that you must be well versed with your business process. If you don't, you're no better than the 2500-rupee whizkid from Chennai who can bang out an EDI map. An EDI analyst who has a good grasp of the business concepts, and who can partner with their internal business partners AND their trading partners, will never lack for work.

I moderate an EDI mailing list (1)

rah1420 (234198) | more than 9 years ago | (#13582501)

We're grudgingly letting Yahoo host it but if you want, come on over to the EDI-L [] mailing list. Messages are viewable by the public.

I have a few years of EDI experience as well, and it's my day job. I don't mind knowledge transfer either.

Re:I moderate an EDI mailing list (1)

DaveCar (189300) | more than 9 years ago | (#13599799)

This is a useful list. I've done some EDI too and written an EDI parser ( [] ). It may be that you'll be needing much higher level packages, but a Perl API wrapper works for me.

Links (3, Informative)

isj (453011) | more than 9 years ago | (#13583808)

Knowing what to search for brings up these relevant links:
X12 []
How Radio Frequency Identification Affects EDI []
Integration for Logistics: RFID, EDI, XML, and Beyond []

If you are using an off-the-shelf inventory/billing system they you should probably consider letting someone else handle the integration and format-translation.

I have implemented an EDI system from scratch at my previous company. It was based on EDIFACT and email, and had extensive tracking&tracing, status feedback, error handling. The major challenge in implementing and EDI system is the integration with your EDI partners. It took 3 months from start of testing to the first real EDI message getting through, and almost a year before the workflow was right. Another challenge is that touches on legal responsibility - who said what, why, when.

I believe that ROI was good. No more manually entering 5 batches of 100 items every day. And the deadlines were improved so the final information set could be imported half an hour before work was initiated.

As far as I know the system is still chugging along 5 years after I left the company.

You know those TV ads... (2, Insightful)

John Harrison (223649) | more than 9 years ago | (#13586736)

where the punch line is something along the line of, "Now is when you realize that you need IBM." Well, guess what?

Seriously though, you need to get someone that has massive experience doing this sort of thing and doing it in anger.

EDI (1)

tr0tt3r (544366) | more than 9 years ago | (#13587391)

EDI is an interesting problem because it is one of those standards that we all just wish would go away. XML would work just as good, but if a EDI partner has a working system based on EDI... well then EDI it is.
I am the author of FreeB [] which is the first GPL medical billing engine available under the GPL. One of the standards that we support is a classic EDI standard, namely the X12 837p4010a medical billing standard. Hairy beast.

We have had a surprising amount of success using, of all things, PHP and Smarty. In order to handle the random variations that EDI interfaces call for you need a robust templating language. You must be able to seperate data from formating = templating. Smarty is an excellent templating engine! PHP/Smarty is very good at removing data from a database and then pumping them out in arbirary formats, which exactly what you need.

You could take a look at some of the FLOSS EDI libraries out there, but ultimately the feature you need is templating.

Fred Trotter []

Take a step back (3, Insightful)

gmccloskey (111803) | more than 9 years ago | (#13588096)

You're a techie, but this is no reason to start off with a solely tech discussion. As a former techie, and more recently a consultant, here's my spin:

(1) get your boss to write down the business reasons for the change. Not technical reasons, business - cost savings, productivity increases, etc.
If there aren't well defined reasons, then you can't technically come up with a solution that's much use, as they haven't defined the problem for you.

(2) Get your boss to write down the goal of the project. This is usually a single statement. Eg if you worked in an oil company the goal might be "deploy a pipeline from turkey to russia that can carry 5m L oil per day". If he won't write it down, you write it, and get him to approve it formally.

If he can't or won't, then you don't have a baseline to judge all future decisions against. I.e. whwnever you have a question or problem, ask yourself does it help or hinder this goal.

(3) Figure out what the parameters of the deployment should be: think what, when, why, how, where. E.g. it should be completed within X months, should not cost more than $Y, should be availble in Z% of offices, should not take more time to complete a transaction than the exisiting system.
These parameters help define what you should and shouldn't do, how much resource to devote etc. Basically they give you the rules of the game.

(4) Figure out who the stakeholders are - ie who is affected, and who has power within the company. This typically includes the fincial director at a high level, and end-suers at the low level. Speak to the FD - he often has final say over everything, and has his own set of expectations different to the IT director. Speak to the users - they can suggest problems that need to be fixed, and things that work and they want kept.
Knowing the stakeholders and keeping them informed and happy is the biggest challenge.

No offense, but you say you're a 7m technician intern. This makes me suspicious they putting a core business function in your hands that if fucked up could kill the company.

I suggest after doing basic research, going back to the IT director and saying something along the lines of "the total cost of switching, impacts on the business and risk to business interruption are not clear. Yes the current solution might look expensive on paper, but it might be less expensive than swapping. We need to scope this in a bit more depth, and possibly engage outside experts for a small study to understand costs, benefits and impacts." then hand him a short list of potential expert companies that can help. by this stage you'll have called these companies, and in general terms described your problem, and checked out if than can help, how and will it cost. You'll have names, phone numbers and email addresses for all of them.

I agree with the others when they say EDI isn't something to take on alone. Use the experts. If you've never project managed before on any scale, I suggest you get help with that too - internally or externally.

Best of luck. this can be a great learning experience.

Ps if your company throws a wobbly at any of the things I've suggested above, tehn that means they're not serious. Find yourself another job, they don't pay you enough to deal with bad management on top of everything.

webMethods (1)

sonamchauhan (587356) | more than 9 years ago | (#13588270)

Congrats! Looks like the boss sees dynamism in you - give it your best effort, but be realistic and don't be afraid to ask money to implement an effective solution.

EDI can be mind-numbing. You'll need attention to detail, clear headed thinking, very good and very tightly controlled documentation, and a well thought out and documented processes for new EDI-partner implementation and existing-partner transitions.

For software, try getting something that simplifies life as much as possible. If your company is willing to spend a fair bit consider buying an off-the-shelf solutions.

webmethods: [] is a good solution. I've been using it for 5 years at work. It's got a good name since lots of people have had success with implementing EDI with it. The best open-to-the-public webMethods user website is [] - even if you don't use webMethods, searching that site for terms like "X.12" and "EDIFACT" will give you a sense of how others implement EDI. Here's an article by a friend of mine: "Create Positional Flat File Templates for the WmEDI Parser" l []
Note, this article is for ver 4.6 - I understand the current version of webMethods (ver 6.5) has a different, graphical, EDI parsing engine. Other articles: []

The good thing about webMethods is it's got a visual-progamming IDE that simplifies life a great deal, and that it's really a webservices/XML-centric solution that also handles EDI - so in future, you can move forward to cXML, xCBL, ebXML, etc, which are XML-centric standards. (For the respective websites just append .org to these names). They also have support for stuff like RosettaNet and RFID, but I'm not familiar with the specifics.

The one thing webMethods does not do well is FTP file spooling for pickup - it does built-in FTP clients and an FTP server (can only submit documents to it), plus VAN and SFTP support. For FTP spooling, you'll need to run a separate FTP server.

webMethods competitors include TIBCO, Commerceone (conductor), Microsoft (with Biztalk), IBM and BEA (not sure what). There are also the old distinguished EDI translators like GenTran.

Google shows up a couple of open-source solutions as well: [] []

Hm, maybe I should do a sourceforge search. Aha, quite a few matches: &words=edi&imageField.x=0&imageField.y=0 []
Don't know how good these are though. If you evaluate them, try posting back here if you can.

Whatever solution you choose, when you do build a solution, try making a 3-layer
solution, with a middle layer of canonical data structures isolating the B2B/EDI standard from your backend-system standard. For eg: as mentioned in my article here: shtml []

Also, no matter how well you implement a standard, you'll always come across situations where you need to customize a B2B/EDI implementation because your trading partner sees the standard differently than you do - try building an architecture that enables easy customizations. Also it's important to implement automated integration and system testing (most people only try and automate unit testing) - as you build functionality, keep adding tests to your test suite.

look up these two packages (0)

Anonymous Coward | more than 9 years ago | (#13600342)

look up ...

Trusted Links for Windows
Trusted Links for the I series (as400)

made by innovis ;-)
Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?