Long-standing ECGrid clients, such as Covalentworks and SPS commerce, typically access ourservices via VPN, yet are in a very real sense beneficiaries of the API. This is because we provideupdates, enhanced functionality, and special account handling features via ECGridOS web services.Therefore, all LDC clients share in the positive improvements catalyzed by the API. Many have astated intent to plan future projects around ECGridOS, or already have developer credentials.
ECGridOS is a Full Internal Production System
As for ECGridOS developers, the first and most important client is Loren Data Corp. We deliver allnew client facing features and management functions using the exact WSDL calls that are madeavailable to our developers, with only a handful of functions reserved for internal use..
Marquee EDI Entrepreneurs bet their Farms on ECGridOS
The current developer of record is NetEDI. Although NetEDI is a non-domestic reference, theycurrently hold the largest code base relying solely on ECGridOS. We expect NetEDI to perform landoffice business in the EU. The principals of NetEDI are experienced EDI developers, .Net aces parexcellence, and have delivered on every conceivable B2B and ERP platform.We are very fortunate to have NetEDI in our developer portfolio. I would highly recommend thatanyone interested in these topics consider NetEDI as a source of industry intelligence, quite apartfrom his ECGridOS exposure, for his perspective on the B2B tools sector is penetrating.We have assigned credentials to a list of developers closing in on a baker's dozen + a good handfulin the pipeline. These speculative prospects run the gamut from OEMs to SAAS 3PL hubs andautomotive vertical SCM. We expect contractual agreements from a subset of these.
Conversion of Accounts
When a prospective developer 'gets it',
they are in
. Therefore, our contacts with technicalmanagement depends on how CTO's and Tech VPs are positioned.The conversion from prospect to paid services can be sudden. Particularly in the cloud B2B sector,where the fight for differentiation seems to be heating up. We expect to hear from ECGridOSdeveloper account holders (the occasional or dormant) in due time. Their initial intuition is usuallyspot on, even if coding efforts are somewhat delayed. The original intent to develop will reassertitself.An increasing resource pool of example code, tools, and helpful utilities will serve to awaken someof our shy developers.
Pure WS vs. Adapters or Both?
Regarding adapters: We feel that current IDEs handle rational WSDL grammars as well as platformspecific adapters. Time allowing, we plan creating a Boomi Atom, a WCF or App Fabric Componentfor Biztalk server, and we may throw a dart at other SAAS enabling multi-Tenant platform, such asNetsuite OS, Mule ESB, or some-such.
Web Services
are consumed directly by SAP's xi, ABAP, Sterling Integrator, Biztalk, Visual Studio,Eclipse, Web Sphere, and other platforms. The creation of specific adapters may only serve totransform otherwise well documented WS functions into an arbitrary alternative. Clean, unified welldocumented WS Calls, or a REST family equivalent (depending on what religion you grew up in),are far superior to a fragmented set of one off adapters that must keep pace with the quirks andvagaries of the targeted host system.