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
