Archive for the 'EDI Software' Category

17
Jul

Doctor, doctor, give Me the news…

I’ve got a bad case of … EDI VIRUS BLUES?

The other day - on, yes, the EDI-L Yahoo Group - I read a post about how an Information Security department of a company was worried about the concepts of viruses and hackers gaining access through the EDI system and the documents we trade via EDI.  Most of the replies were, as you would suspect, “is your infosec group smoking crack..?!?” or something to the same thought..

But it does beg the question - how susceptible to a virus attack, a trojan horse, a hack or some other kind of attack are we through our EDI processes?  There are no virus scanners and other system tools to scan the data as it’s coming into the system via our AS2 or bisync communications sessions.  There’s not much to stop the virus or hack or trojan from getting into the system, now is there…?

Sure, you may have a firewall set-up and the data must pass through the firewall, but you’ve basically given it permission to travel through that wall, anyway, simply by virtue of the face that you’ve given permission to the connection that the data (virus laden or otherwise!) is traveling along.

But that’s about the place when their concept of the attack falls flat…

Look at the way the data is transmitted - more or less as text - viewable as either the hex format or the text format.  And then your translator will go and take those characters and put them, based upon your mapping specs, into your system and populate the various files and data fields that you’ve mapped them to.  That traffic cop of EDI translation is directing the data flow into your system(s) to create orders, receive orders, and so on.

And it’s truly your translator and your map that will end up acting as the virus defense line - by virtue of the fact that the data that they could be sending (that virus code!)  will fail in the translation and never make it into your back-end system.  Even if they use one of the simplest hacks - a buffer overflow - you’re still pretty much safe - simply by virtue of the fact that they can send all the characters and data that they want in the element, but you’re only looking at 10 characters.  Or 12 characters.  Or however long that data field is.

The other thing to remember about these files that we trade back and forth, however, is that they’re treated and send (basically) as a text document.  Nearly all virus programs and worms and trojan horses are programs… They’re EXECUTABLE files.  They’re sent as screen-savers or zip files or whatever - but, at their root - they’re an executable file - a program.  This concept was brought up in the thread on the group, too.  And of course, the doomsday nay-sayers kept on about how you could get the malicious code into your system.

The best counter example to this, however, was the concept that I could create a wonderfully wicked virus - something that would truly erase all of your files on the hard-drive, recreate your “Favorites” (for Internet Explorer) with porn sites all about farm animals, recreate the Unabomber’s manifesto (as written by you, of course) and change all of your image files to naked images of the gender you least want to see naked…  And they’ll all be over 400 lbs of fleshy beauty.  Oh, yes, and your computer will blast - not just play - show tunes and 20s-flapper jazz at full volume…  Yeah, now that’s a VIRUS!!!

But the truth is, I could create this showstopper virus and send you the code - as a .txt file that you could open and view in Notepad or Word (or whatever writing program you use).  But will it cause any harm to your system..?  Nope…  Will those aforementioned show tunes and nudie shots render your system a disaster area..?  Nope.  All because it’s a set of instructions, but they’re not presented in a way that the computer will actually process them and follow them.  They’re nothing more than words - letters, numbers, symbols - characters - that you can view.

EDI documents are the same thing - they’re just characters that you (or your system) reads and populates into those certain fields and files.  They don’t do anything other than that.  It won’t open your ports, start the modem in a receive mode or anything else that could compromise your system.  It won’t go digging into your financial data and give access to any of the credit card data you’ve got stored or give the hacker the keys to your checking account.  They’re just text - readable collections of characters. 

So, go ahead.  I dare you.  I double dare you.  I triple-ripple, double-dog dare you.  Create a virus to be sent via EDI.  And see how many systems you infect.

One of the other things to consider - even if it WAS possible to create a virus and send it via EDI - would it be truly worth it..?  One of the bombs that often shows up on the battlegrounds of the Apple Mac vs. Windows PC wars is how safe the Macs are from viruses and attacks.  And it’s not that they’re truly safer or more secure.  Instead, it’s the law of “supply & demand”.  You’ve got hundreds of thousands of Windows PCs out there in the world.  Millions.  But only a few thousand Macs (by comparison).  So, where are you likely to get the most “bang for your buck” when creating a virus, hack or trojan horse?  By infecting 10% of the population?  Or is it by doing the 90% of the population?  That’s right - it’s the 90% group you’re going after…  You’ve got the most chances for your seeds of evil to dig in and root and create the mayhem and carnage you’re hoping for.

EDI provides that same kind of safety, as well.  There has to be so much forethought and planning on the part of the hacker - he’d have to create a document format in a document you trade AND he’d have to create the map with the specific communications parameters (qualifer, ID, network, etc.) and all of it in a format that your system would allow to translate AND move into your production fields and files. 

Sorry - ain’t never gonna happen….

But, what’s YOUR take on the chances of virus attacks in EDI..?

Author: Craig Dunham - EDI Coordinator @ Big 5
Read more about Craig here: http://editalk.com/contributors/
09
Apr

Microsoft BizTalk / eBridge Webcast - Empower Your Business Process: Transact and Integrate with EDI

A member of the site emailed this into us today, its an upcoming Webcast on eBridge and BizTalk.

Empower Your Business Process: Transact and Integrate with EDI

eBRIDGE has partnered with Microsoft® to bring you an informative webcast on how eBridge integration can streamline your business process and increase the value of your Microsoft Dynamics™ ERP by eliminating timely and costly manual data entry.

This presentation will demonstrate how a complete EDI document exchange and integration system is achieved with the ePortal Software-as-a-Service (SaaS) platform from eBRIDGE Software.

Through the power of BizTalk® Server, the ePortal handles all data routing, communication, translator and mapping services. Document transactions can be viewed from any station that accesses the internet.

Click here to register for the Webcast.

09
Apr

Ch-ch-changes…

Ch-ch-changes… Turn and face the strange…” - David Bowie belted out back in 1972.  Well, 1971, actually, but the song wasn’t released until 1972.  And, as usual, I digress in the details.  But still, some of the lyrics are quite appropriate today.  And especially in the world of EDI.  Good ol’ Ziggy Stardust (aka Bowie) sang out:

                                   “Still don’t know what I was waiting for..

That’s something we hear a lot in the EDI world - once somebody finds out how well EDI can help them.  They don’t know what they waited for - or balked against - when given the option of EDI.  Once they’ve seen-the-light, it suddenly becomes a no-brainer.  But at the time, it was strange and unknown and a change.  And we all know what people can be like when it comes to change.. Don’t we?

  • Change is hard!
  • What’s wrong with the way we’ve always done it?
  • Oh, great!  Now what do I have to learn?

Right now, I’m working with our Accounting group in getting them to embrace and accept the 810 EDI Invoice.  And, for the most part, I’m lucky that they’re open and willing to “face the strange” and go with it..  However, where it’s making My life a living hell is that they expect everything to be done.  Now.  2 Minutes ago.  Yesterday.   ASAP.  Jump!  Jump!  JUMP!!!

Think about the time that you first began to become a part of the EDI world  You probably came from some kind of MIS position - either an operator or a programmer or an analyst or .. Or, you came from another group that your EDI program touches - either the accounting group or the buying group or the warehouse group  or .. Well, you get the picture.

                                        Embrace the change..

And think about the changes (Ch-ch-changes) that you encountered along the way.  Think of how you had to ch-ch-change the concepts that you held and others kept of the way things were and how they were going to be.  Think of how you and others in your organization had to ch-ch-change the way you did things - things that had been done “that-way” for years (or even longer?)..

Some of the pods of flesh on this planet are pretty adept at change.  Others - well, not so much.  No, they’re like the stubborn mule in the old Western-Comedy, leaning back, digging in their heels and not budging.  It takes a lot of force to get that immovable object to take that step forward and “embrace the change”..

Then you sometimes have to try and keep up with those changes..  In recent articles, we’ve touched on many of the changes coming to and infecting EDI as a concept.  Things like AS2, XML, E-Catalogs..  Ch-ch-changes, indeed. 

But are any or all of these changes going to help or hurt you..?

And how good are you at accepting and going with change..?  How good are you at accepting change and working with it and finding the solution to the newest ch-ch-change coming at you..?  Think about your daily commute to and from work.  There’s an accident at this highway and that street.. or the road is closed because of “police activity”..  Or there’s some guy protesting ________ (the war in Iraq, China’s hosting of the Olympic Games, gays in the military, our government’s failed policies, the new Wal*Mart coming to town, whatever - fill in the blank) from that bridge, hanging a sign over the highway..  How quick are you to think - “hmmm.. I can detour here at Main Street, go down 3 blocks to Fifth Avenue, hang a left and be back on the freeway beyond that problem”..?  Or do you just sit there with a bunch of other commuters, waiting for your turn to squeeze through the half open lane to pass by the wreck, not willing to deviate from the norm?

How well you handle change means a lot - both professionally and personally.  Change is an integral part of life.  It’s something that creeps up on us on little tiny quiet feet or comes barrelling into the china shop and disrupting lives all around.  But change is inevitable - just like death and taxes.

And change is big in EDI - no matter how static and stable the platform and concept may be.  There are - and will always be - changes to the way we do things.  Standards are often being updated.  Segments are added or deleted from the document specs.  Suppliers and buyers are often requesting new information to be sent or received.  New applications are added to your back-end systems and now you have to map this segment/element to this other file and record over there.   The PO box you use to received payments or invoices has altered names, and the data in your documents (POs, Invoices) must reflect that new alteration.  You’ve adjusted your factor or payment “lock-box” location or service provider.  You’ve signed up with a new VAN/Network and have a new qualifier and ID..  All of these are ch-ch-changes.

               “I watch the ripples change their size But never leave the stream..

These are just a few examples of the ch-ch-changes you may face.  And there will be many more, too.  I’ve had our EDI program up and running - well - WE’VE had our EDI program up and running since the very late 90s.  About 5 years ago, we changed our translator (upgrade) and then added a new document (the ASN) and added and expanded our trading partner count by .. well .. multitudes.  Then we added some information to our PO (requested by some of our suppliers) and changed a terms code and .. well, you get the idea.

Ch-ch-changes are important and everyday.  Expect them, plan for them and implement them.  And do not be afraid of them. 

Author: Craig Dunham - EDI Coordinator @ Big 5
Read more about Craig here: http://editalk.com/contributors/
31
Mar

EDI Chargebacks!!!

WHOA!!!  In My readings, I just came across this article over at EC-BP.org!  Looks like we all get to start paying for our EDI transmissions!! 

Author: Craig Dunham - EDI Coordinator @ Big 5
Read more about Craig here: http://editalk.com/contributors/
20
Mar

How do you EDI?

Well, guess what - I was reading (go figure!) a newsletter from another site - E-Commerce Best Practices (ec-bp) - and they had an article - that itself - was excerpted from the EDI ACADEMY - all about “EDI to FAX and FAX to EDI” types of communications. And it got Me to thinking. Yes, again.

One of the things that I’ve always had and dealt with in the past with My own EDI program for My employer.. First off, we have our own in-house solution for EDI. We use the Inovis TrustedLink i-Series program - and have for years - and pull directly from our merchandising system on our AS/400 - sorry - Series-i system. We populate back into that merchandising system (Island Pacific) and also our WM system from the inbound ASN documents. And with the new 810 Invoice that I’m working with our accounting department on, I’ll populate from that document, too.

But, again, in the beginning, there was the expansion of our program - trying to net as many of our vendors and suppliers and getting them on-the-hook and in-the-basket for EDI document trading. Now, it should be said that of our 1700-plus vendor rolls, there are some duplications - in that this product line from Big Vendor A is set up differently in our merchandising system than some other product line from the same vendor. What this means, is that I may have multiple vendor numbers assigned to a single trading partner - all based upon a product line or a division. Apparel is different from footwear which is different from hard-goods which is different from cleated shoes which is different from winter snow-wear and .. well, you get the idea.

Then, of course, there are still entries for vendors that we may not be currently doing business with - but we’ve dealt with in the past - and there is a chance (no matter how slight!) that we may just buy from them in the future. So they’re in that 1700-plus listing. Add to this, the “factors” and remit-to entries for all of these vendors, if it’s different form the “main” vendor set-up. In cases of the multiple vendor numbers (as described above) we may have them all pointing back to a single vendor number - the remit to - that we never buy from, but all the checks are sent to for invoices.

And then there are the SMBs - the Small and Medium Businesses - that we buy from. The small mom & pop company that makes the best darn badminton shuttle-cock in the world.. now I’m wondering if I spelled that right. Anyway. They make the best dang _____ in the world - and that’s ALL that they make - and we buy it from them a few times a year in some decent quantities.

Or there’s the case of the one-woman show that we order some cooling necktie bandanna kind of things from - she runs the entire operation with a part-time receptionist/secretary, but takes care of all sales and marketing and manufacturing aspects and dealings all by herself.

These are the kind of small and medium businesses that need a super low cost solution for EDI - these are the kinds of businesses that rely upon something as “un-EDI” as the concept of EDI to FAX and FAX to EDI. And sure, there are often just as inexpensive web-based EDI solutions out there - but these small business owners don’t have the time or the inclination to learn the system. Or they don’t like to get on the net - because they only use it for e-mail and even then it’s through dial-up and it’s slow, but it’s simple.

At the beginning of our EDI expansion a few years ago, it was VERY IMPORTANT that we have some kind of solution for the (very-possibly) less than tech-savvy vendors - that solution for the small guy that only has one computer and doesn’t have the time or inclination to get online to find out “you’ve got orders!” Our provider (remember, Inovis) - well, at that time, they were still QRS - worked on and created a great fax based EDI system for use with these vendors and trading partners. When Inovis took over QRS, they sold off the solution - called MEC (Managed ECommerce) to ICC, who now handles those clients.

A while back on the EDI-L Yahoo! Group, I was involved in a discussion of “what is considered EDI” (don’t remember how long ago and didn’t feel like searching through the old posts to find it), and I commented on how these kinds of documents are still considered EDI. And even being able to find a way to e-mail an order - or whatever documents you’re trading - is still EDI. EDI is Electronic Data Interchange, right? And isn’t, at the MOST basic level, an e-mail or a fax a type of EDI..? We’re sending data, right? It is being done in an electronic format, right? Just as we can trace back the data we’re sending - no matter how sophisticated - back to those 1s and 0s (ones and zeros), we can also trace these back to tones and blips and beeps that are sent over a phone line. Is this an overly simplistic explanation of it? Sure, but so is how I liken “EDI document trading” to “e-mail sending” to those less-than-tech people I deal with in other departments.

Even though many of us are pretty technical in our abilities and our ways of thinking, we need to also remember those that are not that technical. Yet they’re also people that are extremely important in the grander scheme of the WHY we’re doing EDI. They’re the buyers that create the orders. They’re the small mom-n-pop companies that make the product we buy and ship it. They’re the former nurses that work in the records room that send your medical history to the new hospital. They’re the math and accounting bean-counting pros that pay the bills and keep the ship afloat on the financial seas.

Even though we’re looking at EDI to FAX and thinking “how quaint, how archaic”, we have to remember all those other eyes out there that will be looking at and working with the data and the documents we trade without our knowledge and our tech-savvy.

Author: Craig Dunham - EDI Coordinator @ Big 5
Read more about Craig here: http://editalk.com/contributors/

 




Contribute to the Community

EDITalk.com is run by EDI guys for EDI guys. Want to write a article or blog post? Just let us know on the fourms and become a contributor today! All credits given to any article posted on the web site.

Categories

 

August 2008
S M T W T F S
« Jul    
 12
3456789
10111213141516
17181920212223
24252627282930
31