Wouldn’t you just love to know about the profoundly messed up routing architecture of VANs, how they work, and what kind of software and systems they use? How do VANs implement 12.56 interVAN signaling? Interested?
Well, you are out of luck. There is precious little or no software available for VAN operations, and absolutely no commercial software that can be unwrapped, installed, and delivered to enable, “here is your VAN, yo!”
Most VANs have some code, some OS scripts, and some backend DB stuff for account management. The level of systematic cohesion to manage accounts at the Professional Service Provider level is questionable. The ability to handle mass account migrations and even the daily system level support of an SPS or DiCentral type of account, with 10’s of thousands of users is a crapshoot. But if we did want to see the fundamental primitive operations of an EDI Network, where could we see it, if we so desired. I’m glad you asked.
The ECGridOS API Documents exposes all of the external fundamental operations of a high-usage EDI Network. Anyone can become an ECGridOS network, we offer free accounts for test and development. But the underlying infrastructure of the machines, code and Net Ops interfaces are of course, another matter altogether. One could adapt, as NetEDI has, a complete B2B commerce network upon ECGridOS. Constructing the data center, or even cloud services based architectures, from scratch assumes knowledge of the VAN world, the basic EDI file header parsing, and all the 12.56 happy horse hockey. The machinery is one thing, the cloud costs are another, the fact there is no commercial stack for VAN Ops is is the coup de grace.
BTW? What is the Real Difference between a Service Provider and a VAN? Just ponder that for a minute.
Now, if you wanted to see what underlies the VAN technical Ops, you could do that by taking a hard look the ECGridOS.net site docs. There are 90+ SOAP Calls and a WSDL description file that packs up the functions for Integrate Code Editors like Eclipse and Visual Studio, there are many ways to inspect ECGridOS Netops API functions, including a linear list here.
So, let’s say you have no interest in becoming a developer or client of Loren Data ECGridOS, or even ECGrid® – but you want to know the down and dirty business of how to create VAN technical operational s solutions? Well, if I were you, I would click on the WSDL link, or better yet, get one of the tools to unwrap the WSDL and inspect the SOAP Function Calls that comprise ECGridOS – and now, there are 90 of them covering every conceivable aspect of running an EDI network – including some functions that most VANs simply can’t do. I will not say what these are, but clever, savvy programmers and engineers will look at the ECGridOS API and say, “I can do a great deal more than commerce functions, there is whole network file systems here with manifest management an a plug-gable routes configuration. Say whaaaattt? Yes, we knew, rather Todd knew long ago that the VAN based start connection scheme was a loser – and that just like the internet that all of our traffic goes through, EDI will, eventually, be hierarchically routed. VAN interconnections are for chumps, and we have started the liberation with ECGridOS – use one web services connections and get all of your interconnections here with Loren Data Corp, at the best rates, until the tyrannical system of KC’s and BIGVAN hegemony is killed off in a year or two with our fellow colleagues and EDI rebels, and the cadre is gathering, I promise you by my life.
Because the code level integration of ECGridOS allows EDI Network functions to be glued into products or SAAS services, you are the VAN, you are the network and the comms functions now reside in your product. You shall assign functionality to users what you have always wanted to grant and access, but never had the chance in the old world of VANs, as you had to go to a web page to set mailbox configurations, or email the man at the VAN, or call some drone on the phone. Those days are so over.
The ECGridOS SOAP function list proves that you can recreate a VAN’s communications repertoire. That’s what we did. ECGridOS did not exist before ECGrid® did!
We have operated ECGrid for over ten years as a very busy, viable, commercial EDI Network hosting the largest On-Demand commerce companies, like SPS Commerce, ESG, and many others. We already owned and operated VAN infrastructure that exceeded the largest VANs, who are actually particularly not technologically agile at all. The industry standard has remained rather stagnant with FTP and As2 handing off files that you practically kiss goodbye after sending. The VAN world has been woefully inert.
But, ECGrid supports directory services and manifests – so we rolled up our sleeves, and created a Web Services proxy and a new Domain Specific Language for ECGrid – OS.
This is how you make a VAN
That’s right: We created a VAN operating system for EDI communications and trading partner community management. It is a fine, state of the art system where a service provider, one who has everything except VAN interconnects, can create an entire suite of VAN and managed file transfer OS integrated services, including user control sessions, mailboxes, well, come on, there are 90 functions here. Better than FTP, AS2, better that any large MegaVAN, supported by a community of developers and the principal network engineers. Yikes. So much better.
So to create a new VAN, study the ECGridOS functions. Then, buy a data center and create the application calling code, hire a net ops staff, and get your first clients to subsidize cashflow, then call us back, because in the end, you will really really need ECGridOS, because you will be broke by that time! Just ask Edison Carter, he knows.
Or, just start with ECGridOS. We did this all for you, for anyone who has thought or said, “How can I be my own VAN?”.
