A big part of my job is working with these third party business software packages. They call them ERPs: Enterprise Resource Planning applications. They’re basically Quicken on steroids, allowing you not only to Balance Your Budget but also Track your Inventory and possibly even Forecast The Future! They’re the little brothers of those monstrosities you see at big corporations like Peoplesoft, but they pretend to do everything the big guys do, meaning they do a crappy job at everything.
You might be able to guess that this is by far the favorite part of my job.
What I need to do sounds simple. Our software receives a purchase order, which we need to shove into our customer’s ERP. Then, when they invoice or ship, we need to rip those documents back out of the belly of the beast to send on to their partner’s. We do some other stuff, too, but let’s just focus on the basics. Shove in, rip out. Repeat. A lot.
That it sounds easy should tell you that it’s not. The science of API design is, in my eyes, still feeble. That may be changing with a lot of the really interesting web APIs being build by Google and Yahoo and Twitter and whoever else, but on the desktop side APIs and SDKs are afterthoughts. They’re added when executives realize, late into the game, that an application which someone can Program At may sell better than one which can only be used through the buttons visible through its UI. It’s then implemented by programmers, who have built an application whose buttons may not do their desired tasks as it is, in the fastest fashion possible.
Then, at some point over the next year, they start trying to fix it, at which point it simultaneously gets better and worse. Better because it starts technically working, but worse because there’s rarely any way to tell which of the vaguely named methods do what, and because strange new forks in the road get taken midstream, giving the API a case of schizophrenic maturity. Small sections of the API, the ones people have been bitching about, get tons of attention and work perfectly, while similarly structured but different sections of the API appear to be the same but, in practice, are not.
ERPs are now required by Business Mandate to have some kind of SDK/API, but their dedication to the utility of these tools varies wildly. They all have the gloss of professionalism, but under the hood is where the nightmares begin. My favorite, by far, is the SDK of SAP Business One. Its SDK contains two wonderful pieces.
One is the DI-API; the Data Interface for the system. This is what you’d use to integrate with the system from an external application. It’s what we use in most cases, and while we use it for SBO, we don’t use it for everything. Which is too bad, because while it’s twitchy and crappy, at least once you’ve got it working it functions. Oh, sure, they decided to build it so that it’s child’s play to update the client software without updating the SDK, leading to confusion and frustration when the integration “suddenly” breaks. But other than that you can, you know, shove things in and rip them out. No big deal.
No, it’s the second piece that is the true star of the ERP Nightmare Circus. It’s the UI-API; the User Interface API. On, how the fun begins. They have something like three ways of building forms, none of them great. One is driven off of XML. Another uses an add-on called Screen Painter which, at the time we developed the solution, didn’t work. Finally you can just build the forms through the code. Or if you’re like most developers, you can mix and match wildly. Fun!
The UI-API allows installed add-ons to block events from reaching other add-ons. This is one of the best features, allowing developers to accidentally break each other’s add-ons with gleeful abandon. What’s best is that nothing errors out, exactly. Things just stop working. To sweeten the pot, SAP also offers no Add-on compatibility testing at all, so someone selling these add-ons has no idea if they’ll mix safely unless they test them on their own. You can imagine, I’m sure, the joy in customer’s voices when two things they paid money for break their entire system.
This is in addition to the kind of shoddy documentation and barely useful testing tools that all APIs come with. And I shouldn’t complain too much: the SDK for our software is worse, since it’s still stuck in the “We should have it” phase without having moved onto the “We really need to fix this now” phase. We’ll get there.
Though, since I’m being mean and calling SBO out I should give credit where credit is due. While still a bit buggy, the SDK for Everest Advanced is shockingly good, with OK documentation and a test tool that really saved my butt while I was developing for it.
And I’m still looking for a good, dirty riff on ERP.