I can definitely tell you one of the top question I get about ECGridOS – here it is: Who is using it? Most of the folks asking this really mean, “what type of developer or B2B IT entity is using ECGridOS API Communications services?”

Here goes:

Tech Savvy B2B Entrepreneurs looking to differentiate their offerings:

1) NetEDI and Dimension Software use ECGridOS to add full, better than VAN-like Trading Partner Communications and Management  to their unique solutions. In the case of NetEDI, they have built, from the ground up, a complete EDI business using their extensive experience in B2B integration. The folks at NetEDI use ECGridOS as their communications engine and network management backbone, an anchor service that complements the company’s extensive other fully and seamlessly integrated services.  See their offerings at http://netedi.co.uk

Dimension Software uses ECGridOS to add EDI Communications to Orbis Task Centre – an advanced, encompassing BPM suite that is making its mark in the supply chain solutions arena. Jesper Carstensen now distinguished Dimension’s offerings by bringing fully integrated EDI Communications and vendor management to Orbis’ great BPM suite. I would actually say that calling Orbis Task Centre a “BPM” product misses the mark, its really a powerful  application environment.  See Dimension Software at http://dimensionsoftware.dk/

2) Established B2B Software Companies and Service Providers that want to make EDI as seamless and painless as possible for their customers.  What better way to take the sting out of EDI’s sometimes vexing comms management, than to integrate trading partner management and  EDI Communications into the software or B2B SAAS service?

ECGridOS gives established Supply chain IT vendors the edge with 150+ function calls,  including instant AS2 hub creation and fully routed EDI messaging to over 100 different VANs, direct hubs, Federal purchasing, and other EDI compatible systems, globally.

Examples of established B2B companies using both ECGrid and ECGridOS include: Radley, SPS Commerce (ECGrid), Energy Services Group, Epicor / Activant (coming live soon), Oakland Software, and Covalentworks.

How many developers are there, either in development or live on Loren Data Corp’s network?

We assigned developer credentials to around 45 developers, and we see active programming and debugging activity from about 15 of those, some 7 odd accounts suddenly start calling functions at long intervals, and the other half are inactive. NetEDI , Dimension Software and Radley are the leaders in API calling activity, while we expect another half dozen to go live in a big way within one year. We are keeping our collective eyes on Steve Redler at Thuman’s, the Deli Best Meats – because he is a coding monster.

If you have questions about ECGridOS features or activity, please drop an email to awilensky@LD.com or join our developer forum at http://forums.ecgrid.com/index.php    we also invite our readers to join our mailing list at http://ecgridos.com/ecgridos-developer-news-list-signup/

“Why API?”, is shorthand for, “Who benefits from the 115+ functions in the ECGridOS EDI network management API“?

But first, would we be here at all without the burgeoning community of skilled developers who are now deploying ECGridOS as an integral part of their B2B solutions? I think not! Therefore, I acknowledge our most committed partners, and point most excitedly to their use cases. It’s all you, guys and gals, it’s all you.

Taking Bold Action: A mission critical comms sector in dire need of imaginative engineering – One man’s Solitary Quest:

Operating Systems offer communications services that underpin many applications. SMTP, HTTP, what have you, we expect the ability to access rich communications services as a native function on most platforms, IDE’s, and OS’es. EDI Communications have traditionally been left to the mercies of external service providers, and have not evolved to the point of ubiquity.

The limitations of today’s raw EDI communications services, from any point of view, is a sore subject. New entrants to the B2B market, those with the freshest ideas, and those in the vanguard of the On-Demand Enterprise 2.0 model, are the future of the ‘commerce cloud’ –  these operators are simply unfathomable sources of inspired ideas within their respective verticals, e.g.,  inventory integration, ERP, Logistics, Retail, and hundreds of other specialized market slices that are ripe for EDI aided solutions. These vertical and micro-vertical ventures deserve much better than the limited services offered from traditional EDI communications systems – they deserve native communications accesible from a custom code-base. The very best communications should be integrated with a system’s GUI, or otherwise be embedded at a fundamental level in the back end, resulting in completely transparent communications for the end-user. (Users should not be expected to know the details of EDI communications setup and transaction monitoring - and the fact that many end-users do indeed have to be involved with such arcana, is a blight upon the industry’s house).

Of course, until the advent of ECGridOS, the foregoing was not the case at all within the EDI Communications sector.  Veteran organizations who also suffer at the hands of the ’EDI status quo’ deserve to gain the ability to offer richer services, rather than being stymied by a communications palette that is limited to uploads and downloads, administrative interfaces via a provider’s web page or even more foul, a configuration regime where changes are updated via phone calls and emails to a Network Operations support queue. OMG Yikes (or, Yoicks)!

Such early 20th century communications methodologies are…..unseemly when cast into the role of supporting  and servicing today’s futuristic ‘B2B Commerce Clouds’. There simply must be a better way forward, because it is, after all, almost 2012 !!

Happy New Year

So, yes, EDI Communications has historically offered us a rather boring tableaux of options, and peering into the industry soul,  I see that not much has evolved of late. Therefore, at what point do we, as colleagues, demand the next evolution of B2B communications architecture? Who indeed will deliver such innovation?

The above state of affairs was foreseen years ago by Todd Gould, Loren Data Corp’s President and CTO. Quite independently, while I was working as a B2B Product Analyst, I felt that a change was absolutely necessary for EDI Communications to keep pace with a growing, on-demand world of web based applications.  My analyst’s marching orders were to address the cultural and architectural issues fermenting within the B2B sector. And now, in cooperation with Todd since 2009, we are working to promote the applied philosophy of EDI Communications delivered as a family of platform solutions.

ECGridOS (and the upcoming Superhub AS2 modular architecture) bolsters the ECGrid host network with a 115+function Web Services API – a callable, Domain Specific Library of remote functions, running on ECGrid Server racks in Loren Data Corp’s SAS70 Data Centers. ECGridOS and Superhub are far more than replacements for standard communications methodologies; the API can be invoked, mixed, and matched with FTP, AS2 (externally and within the API), or any channel supported by ECGrid, including SMTP and X400 mail systems.

ECGridOS is to EDI Communications what mobile application ecosystems are to the various app markets (including the communications plumbing) – creating opportunities for new classes of applications that are driven by the fertile imaginings of developers, as well as enhanced interoperability among collegial competitors of goodwill. We do see a richer, diverse, and more competitive market, arising from a well engineered communications platform architecture. Such open interoperability and carrier-class network management provides B2B end-users with more choices, competitive pricing, and a market encompassing true technological innovation. We believe that we have sown in fertile soil, and are prepared for an era of renewed innovation. Participation in new industry (communications) standards  will begin the reinvention of EDI Communications to its true nature – an applied science.

The vision: dozens of competitors building on a a set of defined platform APIs, resulting in an explosion of EDI applications, mashups, and ever more diverse end-users, while also automating what have become all too common –  horribly manual, repetitive, and vexing processes for end-users and network operators alike.

Our initial answer now is Loren Data Corp’s comprehensive communications architecture: (ECGrid / ECGridOS / Superhub), a masterwork under Todd’s engineering guidance. And, hopefully, my endeavors in addressing the philosophical barriers inherent in inter-platform EDI communications. We shall see. We are off to a good start.

How does one busta move in this business(translation, get in)?

The creation of ECGrid®, Loren Data Corp’s advanced host network, was driven by the early Service Providers (like SPS Commerce) who were seeking a next step in the evolution of communications technology. While VANs offered mailboxes, ECGrid offered node level attachement, where the industry at large offered support oriented to the end-user, ECGrid provided a “Responsible Party to Responsible Party” model of support. Where most EDI networks subsumed X12.56 mailbags, Todd engineered ECGrid to promote mailbags into first class, accessible objects. All of these refinements, and many, many more, were engineered into the ECGrid interconnection and message brokering fabric.

Loren Data Corp’s direct, first name basis support model, and its commitment to not service end-users, are bedrock underlying the founder’s long-term vision; Loren Data does not trample client relations by refraining from offering software, integration, or mapping services. Focusing solely on enhanced communications for professional service providers and a new crop of B2B Cloud operators, Todd and his team of five expert, principal operators, are reaping tangible results: ECGrid downtime has totaled less than 11 hours (scheduled and unscheduled) over the course of the last decade. (Furthermore, no outage has ever resulted in a 100% loss of connection availability or intersystem connection capacity, due to ECGrid’s disturbed design. Pretty smart, Todd.

Advanced B2B Ventures and OEM’s requiring an integrated, streamlined communications back-end designed from the ground up for on-demand B2B services, should investigate the ECGridOS API;  Currently, ECGridOS is the only  EDI intersystem commerce communications network granting complete operational authority to its clients. Savvy developers should peruse the online API docs at http://ecgridos.net API docs.

The implications of offering an EDI Communications platform API in the present-era B2B market is disruptive; especially for those giving the least bit of thought to the issues of EDI transaction management. With the industry in the midst of consolidation, upheaval, and some destructive actions driven by the fearful insecurities of its largest incumbent…. well, then, retaining full authority over your EDI Communications has never been more important. Therefore, I invite you to please, join us along with your colleagues who presently enjoy the security, independence, and substantial technical and support benefits of being ECGrid Clients.

I will end 2011 by rapidly publishing the following topical articles, before year’s end. Happy holiday, and a fine and profitable, spiritual new year.

Articles for year’s end:

The State of the B2B Communications Industry, from this analyst’s perspective

The “VAN Exodus” Dichotomy – what does it mean? Does it even exist? What could possibly replace a system that serves a population of 500,000+ VAN trading partners?

The essential truths of Communications infrastructure providers, and standards that we hold them to.

Did you ever wonder  - “what’s involved in bringing an expansive, transactional API to market? What’s it like being the sole EDI Network management API provider? What’s it like to care and feed the ECGridOS API, supporting it, keeping its domain specific syntax relevant, comprehensive,  and easy to use? There’s no other EDI Communications provider offering a platform API; I think if you read the rest of this post, you will see, in part, why there is only one EDI Network Management API Platform provider.

Take a glimpse into the world of “the hardest working man in the EDI Communications business”, while you take a quick look at this link, which is a list of ECGridOS API revisions chronicling Todd’s updates to the API. Wow. That is quite the tour de force, in my opinion. One man and his machines.

To call our President, Todd Gould, a programmer, would be like calling Werner von Braun a rocket technician. Todd runs the company, manages the key accounts with assistance from our incredibly competent VP, Crystal Kuczynski, and our GM of Contracts, Kristine Finlay.

Todd is the sole architect and performs all software engineering for ECGrid – multithreaded core code and I/O modules controlling hundreds of VPNs, dozen’s of FTP and AS2 clusters, EDI software routers and comms node handlers, the mail bagging, archiving, and the administration of MS SQL fault tolerant database running > a million daily database operations, triggers, and stored procedures. All of the love and attention given to ECGrid is purely at the service of our clients, specialized B2B service providers who depend on ECGrid for their EDI Data Communications. All of our network members totaling 23,000 QIDs (addresses) are the beneficiaries of the advanced architecture of ECGrid and ECGridOS API. Not bad at all for a specialized Commerce Data Communications network –  eh?

Never content to sit on laurels, Todd has a product roadmap stretching out at least 36 months. The roadmap is a living thing, and is fed by my industry research, working with our expanding network of developer partners, and from suggestions from major accounts. At the base of the magic is ECGrid, a multitenant EDI Routing system that is, in its native functionality, far ahead of any competing EDI Communications system – but how am I so sure ?

The answer is ECGridOS, the web services API platform for EDI Communications; this allows our partners to write custom EDI applications, or to embed user accesible EDI functionality within Enterprise Software, such as ERP and Logistics management suites.

The ECGridOS API now gains AS2 functionality, and is now in stable beta, with release to developer access before the end of the 2011.  This is an important milestone for the EDI communications community. Here are a few thoughts about why As2 communications was added to the ECGridOS API (a multi-network, mailbag-managed routing system):

As2 is….something else. At first glance, AS2 looks great, with direct connections between the trading partners, secure certificates, HTTPS transport. In other words,  AS2 looks like the answer to what some perceive as our present-day VAN ills (that’s another article). Until one experiences the pleasures of maintaining and operating a large AS2 system servicing dozens, hundreds, or thousands of trading parters, one can’t imagine the complexities ensuing from AS2. Most of the pains are inflicted upon the administrators, especially inexperienced As2 hub operators that are new to the game of communications infrastructure and the direct support of arms length trading parters. All good fun. Not.

Sometimes, a new hub initiative travels down the As2 primrose path, and then finds that they have gone too far, it’s too late to gracefully back out the trading partners onto the (marginally) more rational, routed VAN services. That’s the story we often hear: As2 was thought to be a messiah, yet after adding the thirty-seventh trading parter, things started falling apart, operationally speaking. Big support headaches, big licensing, software support fees, an expanding gang of dedicated machinery,  and never ending End User (trading partner) support calls! I can hear my grandmother saying, “oy vey” (“oh pain”, but much is lost in translation).

AS2, as run by large hubs, is famous for massive and unwieldy “forced march” certificate change overs. Changes to trading partner As2 IDs, the URIs on both ends, firewall port configuration nightmares, etc. Shall I go on?  The lesson here is that internally run and maintained As2 may be an acceptable communications channel for some, a burden for many, (trading partners) yet in any case, is never a picnic for the largest trading hubs.

For the few enamored of large, self-administered As2 systems, that’s great, I will not take issue, however, ECGridOS As2 will improve any organization’s operational efficiency.

I am rather evangelizing 97% of the largest retailers, manufacturers, and logistics operators that have had their sanity stolen by in-house As2. Our brave EDI Service Providers, the communications experts we specialize in serving, also complain about AS2 management headaches they experience in the course of supporting several hundreds to thousands of As2 spoke users.

ECGridOS As2 Web Services allows developers to command a powerful, multi-tenant communications cluster with centralized directory services and certificate management. The AS2 instances you create are accesible by any method supported by the ECGrid host network – FTP, SFTP, As2, Web Services parcel up/down, X400 SMTP.

Salvation is now at hand with ECGridOS AS2. Developers may now create, command, and embed the functionality of the EDI industry’s most sophisticated and trusted communications cluster, unifying both VAN routed communications via standard interconnects, and AS2 communications. Such functionality cannot be purchased or licensed at any price. Yes, there are hosted As2 systems, and they seem as difficult to administer as licensed As2 software packages. For example certificate management in most managed As2 systems seems as fraught as licensed software. Thankfully, ECGridOS As2 is an EDI  Service Providers or in-house developer’s dream.

AS2 instances runs on ECGrid’s infrastructure, residing in a best in class (Sungard) SAS70 data center. No hardware is required, and all of flexibility of ECGridOS (110 Function API) is retained. You will have total control over account creation,  mailboxes, reporting, sessions, security, certificates, tracking, and more. The power in bringing As2 communications to the proven ECGridOS Web services API, remedies the inherent deficiencies of in-house, licensed As2 systems.

If you don’t yet understand my enthusiasm, please go see our API Docs here. This is big.

Making  As2 communications a managed protocol within the ECGridOS EDI network management API is the one of the most newsworthy items I have seen in 2011 – it makes perfect sense, too, as ECGrid, ECGridOS, and now ECGridOS AS2 have all innovations of and by Todd Gould, President of Loren Data Corp, and possibly the EDI industry’s most prolific and far seeing communications engineer.

If you are interested in development using ECGridOS, including the As2 extensions, or would like a quote on standard communications on ECGrid at great wholesale rates, drop us a line or call. Remember, developer API accounts are free until you enroll  production users. We also have flexible account models for every type of Service Provider, Enterprise Software OEMs (build EDI into your applications, instead of sending your customers packing for an external solution).

I hate business gurus. Hate Hate. They never did me any good. After I tried a few magic seminars early on in my career, I gave up. However, seminal knowledge is simply too precious to ignore, and here is yet another aphorism by Master Sensei Seth Godin – I am starting to think that the first three letters of his last name are for real. I have never purchased a thing from Mr. Godin, but I do catch an RSS feed, and I am consistently edified. See the article here. There’s a lesson in there for the current VAN industry.

Kraft Singles owns the market for plain processed cheese in plastic.  I am fairly certain even  gourmet cheese snobs occasionally  pirate a slice or two when  making their children’s lunch. And there are probably Whole Foods analogues to the famous Kraft Single formula –  ”Plain Cheese you can unwrap and depend on”.

Dont try and outdo Kraft Singles. You will lose. Kraft owns the brand.

This describes the VAN industry as of today. Upload, Download, Mapping, etc. Kraft Singles. You want in,  you want to be anchor EDI network, you have your work cut out for you – not technically, per se, but the barriers to entry are immense. We did it in 1999, well, Todd Gould did it, by executing Federal and DOD EDI purchasing applications, building ECGrid®, getting interconnects, and passing the Federal DASC / DEBX certification tests, way back when it meant something. But going forward, we knew in 1999 that plain vanilla services would not sustain the business model.

And here we are, with the most advanced EDI communications system, the only API for enabling autonomous, independent EDI network operations, and a product road map that extends into the future of multitenant e-commerce, far beyond supply chains.

This is occurring against the backdrop of settled services vying for KCs at diminishing rates,  .005 cents at a time. Most B2B integration leaders sell lock-in contracts that do not serve end users at all. The consolidation in the B2B sector has tilted the market, leaving us with a landscape of lost, loss leaders resorting to scorched-earth tactics, managed IT agreements welded to VAN services (John Paul Sarte’s, No Exit) interconnection arbitraging, etc.

This ‘way of doing business’, if you can call it that,  leads straight to regulatory scrutiny and the most unproductive legal wrangling. The leading purveyors of established, “Kraft Singles” VAN solutions, though firmly entrenched,  seem to be wearing their welcome thin; we are constantly barraged with requests to help some poor executive out of an EDI jam; these requests originate not with technical problems, per se, I will repeat, these are not PER SE, technical problems, they are abuses of customer loyalty.  These unfortunate practices are driving prestigious clients to alternative providers, and are catching a few on the fly. These fortunate few are pleased to find that ECGrid offers a very efficient, differentiated EDI communications solution – as different from a ‘Kraft Singles” VAN solution as could ever be found.

Loren Data Corp has no intention of adopting worn out models; and, while every market shelters a few old behemoths of the bygone era, we have always believed in “EDI the revolution”  arising from B2B Service Providers, on-demand web-based innovators at the sharp edge of the market, driving down costs, delivering added value to the SMEs.  And, Loren Data Corp is the preferred network for cloud commerce infrastructure providers; we are simply better at delivering EDI backbone services to the multitenant service providers.

The coming revolutionary, extraordinary EDI applications now being brought to market will exemplify a collaborative model of partner to partner commerce; these models are so fresh, that they have not even been named, as of yet. But, these pioneering ventures will cross the classic supply chain chasm, and break into real-time, dynamic marketplaces – which is where we are placing our bets.

Our product road map encompasses an expansive philosophical-political, legal, and regulatory world-view, has given us a viable platform to build upon. We are just a handful of busy, somewhat overworked network scientists, engineers, and support staff, but we all share a propensity for debate, contemplating the philosophy of interconnected networks, always striving to understand the their next level of impact on  evolving business to business relationships.

The judgement seems to auger strongly in favor of the following: Kraft Singles owns the old market, but such old cheese will not suffice for  dealing with tomorrow’s B2B requirements, so I call attention to the previously referenced blog post by Mr Seth Godin.

Mastery Matters in the Rapidly Changing EDI Communications Business

Wherever I land professionally, the luck of the draw finds me surrounded by fanatics, people with a focus on doing great works. These are the masters. Although I cannot claim such personal mastery at any skill, other than occasional cogent industry analysis, I was an avid bass player in my youth, practicing for hours, a committed free-style skydiver that had a great time trying to become competitive (expensive). I love motorcycles and I have a current love affair with Maxi Electric Scooters, a new obsession. What does all this have to do with EDI and the Mission of Loren Data Corp?

We are a small, tight group of technologists that are immersed in communications sciences that will affect EDI and Commerce communications infrastructure for years to come. Mastery became an issue of particular interest due to this article by career blogger Penelope Trunk. And, with all that is happening here at Loren Data outside of our actual business of helping developers large and small crack the next level of EDI Communications efficiency and Integrated Cloud Power – you know….I wanted to take a moment and highlight what makes this group of EDI Network scientists so, masterful.

Other than the hobbies or avocations of the crew here, I want to look at Team Loren Data’s obsession with delivering advanced network sciences to the EDI business, looking past pushing files around within vertical supply chains, and start looking forward to creating commerce communications tools and services that can be broadly applied to any horizontal or vertical transaction system. As an aside note regarding the hobbies of our merry band, we have am avid sailor, an Ironman triathlete, and a crusader-advocate for children’s diabetes treatment and prevention. All are obsessed with their avocations and their professional commitment to the mastery of the science of EDI communications.

I am hard pressed to see any fresh ideas in the EDI Network business. Technology markets do settle and consolidate; however, seeing the E2.0 sector blow up with venture capital and angel investments, I would expect something, anything noteworthy from the EDI network providers or B2B OEM software vendors. No doubt, there have been some improvements and incremental upgrades, and plenty of lip service stroking collaboration and social business, but do we see any breakout technologies? In covering the industry, I read 400 news feeds daily, I talk to other B2b analysts, and I am still coming up with a lukewarm environment of innovation.

So, in greatly condensed form, here are some of what we at Loren Data feel is worth experimenting with in beta programs, in R&D, or as simply compelling topics for further technical development in B2B communications and applications sciences: Component Network Services and API’s for Service Delivery:

1) The future belongs to the mashup, not packaged interfaces. The great sin of the EDI Communications Industry is in not anticipating the cloud revolution. The richness of Enterprise 2.0, multi-tenant SAAS platforms, seems to beg for rich network services than can be used to build flexible and as yet unheard of B2B applications. Todd Gould, the founder and President here, took the first steps in crafting an API for EDI communications and  session management of B2B applications, starting with the development of the ECGridOS API – long before the cloud was a fully formed concept or common term of art. That kind of foresight takes great vision and the willingness to risk time and resources.

Now that ECGridOS is a proven, robust platform, more can be done by taking this powerful API, and making it work (mashing it up) with other identity and media sharing platforms to achieve, who knows, instant frictionless trading partner pairings? Dream, innovate, and be masterful – we know you will. So there is one innovation delivered to market – the API to create, manage, and embed EDI network services into OEM applications, SAAS, and cloud datacenter services. Viola. One down, and that’s a big one that will keep growing in power as the developer community grows with us.

2) EDI Routing Stagnation must end.  This critical infrastructure is languishing and is fraught with interconnection issues. The EDI industry is responsible for handling transactional messages representing billions of dollars in trade. The current routing system cannot see beyond one leg, offers no alternative or replicable failover routes, and no directory services or ID portability. Whether or not you agree that these particular issues are as important as I portray them to be, we all know that present architectural weaknesses in EDI Routing and Inter-VAN architecture are in dire need of a refresh, imagination, and applied communications sciences.  Such complacency serves no one, not the system operators nor the customers. But the bright spot is that bringing new component network services to market creates more opportunities to build on top, and add value.

Industry advocacy will drive forward future improvements in EDI network architectures. There are existing, modern messaging standards and systems waiting to be adapted.  Thankfully, EDI networks currently run on top of a flexible IP transit network used for commercial email, voice over IP, and many other higher level services and protocols. It’s time, finally, to implement a system that is worthy of  future investment and fertilize the ground for new services.

The overhaul would enhance network operations for VANs, supplier hubs, and specialty EDI networks (like Loren Data Corp), giving us lower support costs, flexibility, and richer value added services layers. (Real value added services, guys, not the, “values subtracted” of today).

3) The trading partners must be honored first, last and always. This means honoring the choices made by the trading partners and not locking them in by: a) fostering alternatives via an active industry of alternative networks and service providers, b) honoring a small trading partner’s wishes to access their supply chains regardless of which VAN the mutual trading partner is on.  Interconnection should remain collegial and non-settlement between bona fide networks, and c) bailment should be considered a sacred obligation – VANs must stand behind their commitment to deliver, maintaining the industry’s current inter-network connections, and investing in future improvements to enhance the ubiquitous mesh of competitive networks should be a pledge from us to all of our customers.

Having covered these issues we are ready for a discussion of the particulars of which specific technologies could be deployed to overhaul the EDI industry. The adoption of standard messaging technologies, adoption of a modern, hierarchical routing system to replace a thoroughly broken 1:1 route plan, directory services to help locate and relocate network subscribers, and the push towards a renaissance in VAN interconnection policy.

These precepts reaffirm the collegial system of inter-VAN relations and the traffic management practices that built our industry over decades – and can only be made better, more automated, and more transparent by competitors of goodwill coming together and implementing visionary standards.

Finally, we need a firm commitment to establish of a set of rules and requirements defining EDI systems interconnection as non-settlement by design. This formality simplifies the rates and relationships for end-users and intermediate system operators (service providers) using the infrastructure of our messaging utilities.

If you operate data centers, cloud infrastructure, or telecom co-location and managed services, are you giving away the potential EDI Communications revenue because the setup, internetwork relations, and interconnections are too arcane? For every data communications service in the known universe, there is a way to obtain the stack, from hardware to software and services; for EDI communications, the choices are bad, and non-existent.

Companies providing EDI Communications services treat even the largest data center accounts like retail customers. These relationships assume you will resell mailbox services, and delegate management and provisioning to the value added provider. There are no options for the integration of pure, unbundled EDI communications services to become a seamless part of your management system or application user interface. All of the important network operation functions, traditionally external to EDI applications, are now, with the advent of ECGridOS, available to the programmer. Operating self-branded EDI Communications from within your application suite is now a proven reality. ECGrid is engineered for multi-tenant and multi-host operations – the kind of businesses managing thousands of QIDs and mailboxes. See the ECGridOS API docs and see that this is not hyperbole, ECGridOS  is a  DSL for EDI Network management at cloud scale. (A Domain Specific Language).

We will assist with provisioning a complete EDI Communications services via ECGridOS API, creating differentiated services that perform as a fine-grained, API level component network infrastructure hosted on ECGrid’s fully managed, node-based architecture. We exceed VAN mailbox functionality by several orders of magnitude (90 function API compared to file up / down) in every category important to profesional services operators.

Undifferentiated FTP that has been shoehorned into multi-tenant EDI applications is a testament to the ingenuity of today’s service providers and their software engineering teams – however, the efforts that such work-arounds has consumed could have been more profitably spent elsewhere. I urge those of you who are deep into B2B service provider system architecture to take a look at the ECGridOS API documentation, and see what we have built for you. Now, ask us for a free developer account and show us what you can do with it.

You will be running real, peer level EDI services in less than a week, integrated with your stack fully in 30days. Ask Edison Carter what he thinks.

How much EDI Revenue did you farm out last quarter, last year? – keep that money, use ECGridOS and be you OWN EDI Network.

As the only EDI Communications Network offering access via API (application programming interface), we must take the lead in creating services that optimize EDI Networking for the Industry Power Providers.  We are a small company, we compete on technical merit and differentiation, on uptime, or handling exceptional network considerations. When things are going well with brand ‘X’ Value Added Network, who cares? When things go very, very wrong…then you want real NetOps, the engineers and owners of the network to handle your massive issues. At Loren Data Corps ECGrid® Netops, the engineers and network owners cover all three support shifts. But there is so much more to the story than “better Netops”!

ECGridOS is the only Web Services API Gateway offering globally routed EDI. We interconnect with a long list of VANs and ecommerce providers; we handle the internetwork peering relationships with cool competence. ECGridOS Network developers, building EDI Communications into products (or as the SAAS B2B system connection), attain a higher level of reliability. If your company runs an in-house As2 or FTP  out of VAN-Frustration, we bring back sanity and save big  money.

We enhance operational reliability. It is all in the EDI Song. Web Services Message handling is the best and most reliable handler of messages – it just is….better than FTP or As2. 

ECGridOS allows ecommerce services, such as on-demand SAAS providers, to assert the EDI Communications authority of a Network Owner – be that a white-label provider, or as a licensed product that has client EDI functions built in – it’s a step up in reliability. If you look at the ECGridOS API Docs , you can see that there are parcel and mailbox functions for detecting network level message issues and failures. By being in greater control over the parcel, you can automate recovery.

Network and message delivery error handling will become even easier, with a set of objects for message recovery. A new implementations of Recipient System Verification, the Proposed ANSI X12 TA3 Standard for Recipient message notification will be introduced by Todd Gould, Loren Data Corp’s President, to the X12 Connectivity Caucus, as a proposed implementation. The whole industry will benefit.

As2 and FTP based systems have limitations in regards to failure recovery. As2 is barely any better in actual practice than FTP. The only people stumping for AS2 are System Administration Gurus who babysit AS2 clusters. We love you guys, but ECGridOS is better, reports better status, implements recovery routines, and is backed with better netops.

We are always better at Netops that an in-house teams – no offense. We offer globally routed connections. Hub and spoke As2 systems, go from system hub to the trading partner. They feel that they are dead-ending, with no routes, with multiple hubs making them repeatedly configure new connections, where there is no upside.

Most larger ECGridOS  accounts are EDI Services Providers, on-demand B2B powerhouses , our ‘never say die’ customers, moving massive volumes of messages. These companies will see the immediate impact of Recipient System Verification. Why, whats the bottom line?

1) Using the API allows competent systems programmers to automate message failure recovery, and to detect message status at the session and network mailbag level

2) This type of granular control only exists in ECGridOS – no legacy EDI Comms service using FTP or As2 can match the kind of error recovery that can pass parameters to your program logic

3) EDI service is all about “exceptions”  - most of the time, things are fine, it is when they are NOT FINE that really counts and distinguishes a real network from a FTP upload and download service

So you want innovation? Evolution of the state of the art? Where are you going to get EDI network services if you are one of a new breed of service providers, a super B2B application hub, an On Demand B2B Power House?

Are you going to BE an EDI Network, or ever more dependent on the increasingly consolidated EDI communications provider market?  Be you OWN EDI Network, with ECGridOS – Sing the Song

If you are planning a new, ground-breaking B2B application, a SAAS ecommerce venture, or are contemplating EDI Communications as an integral product feature (i.e. liberating your customers from external EDI systems), then we have a briefing for you in our Scribd document collection. This briefing covers the different features of ECGrid and ECGridOS, and the various models of Network Ops.  Being your own EDI network is a new model for the B2B ecommerce industry, and  we lay it all out.

CTO’s and Product Managers Briefing

Well, it’s time to update this post – ECGridOS has now been in daily use by several serious B2B service providers since 2010 – continually growing its library of functions . And, the ECGridOS API now has AS2 functionality, in addition to offering message VAN routing. ECGridOS now comprises over 150 functions, granting complete network control to B2B programmers, integrators, and software OEMs.  

That is all

The fictitious EDI Guy in the upcoming final ECGridOS video, shepherds B2B companies across the gap of becoming their own EDI network with ECGridOS.

The SAAS B2B company transitions from a consumer of EDI Communications to an integrated operator of their own EDI network.

The ERP vendor transitions from adding EDI communications at the end of project integration, to offering built in EDI Communications.

“But ECGrid® and the API (ECGridOS) have Globally Routed Connections”, and, the companies that are bleeding money with in-house AS2 and FTP, struggling with  trading partners and vendor support (not their core business at all –  neither are they VAN fans), go with Edison’s suggestion to “get a supply chain, that isn’t a pain in our pocket” – they end up making money by transitioning from self hosted AS2 (dead end connections) to a hybrid system that suppors VAN routed EDI and AS2 instant, virtual hubs.

Your  trading partners will thank you – you are your OWN EDI network, with ECGridOS !

More importantly, our partners have real skin in the game, and are building ECGridOS into their products. It is gratifying that these companies, some quite prestigious, are placing a marker on ECGridOS, making Loren Data Corp more than an alternative to other commerce networks, but making us an integral part of their very product road map.

See then API docs here