DIY Business One automation

DIY Business One automation:  Automation of SAP Business One with the help of the SDK can be quite simple, but for a lot of not-full-time developers (that means mostly customers wanting to build their own functionality and such), it seems to be quite a nightmare. Judging from a lot of the questions I see on the forum anyway.

What makes it so difficult ?

(In my humble opinion) A simple misconception. Most DIY (Do It Yourself) programmers mistakenly believe that any and all automation must happen inside the SAP Business One client.

Now, as most professional developers will attest, the SAP Business One graphical user interface, is a thing to behold. Not in awe, but in horrified disbelief. It is for this reason that all kinds of tools have been developed to help create new forms and/or controls, and to turn all that goodness into so-called addons.

But once our DIY programmer’s initial excitement has died down a little, he/she finds that  getting such tools to work properly, and work with them, requires a serious learning curve of its own, and possibly investment in expensive and/or older third party software.

My point is, instead of automating business processes, our intrepid DIY programmer ends up spending an inordinate amount of time just getting the Business One GUI to behave.

So what then?

Let me give you a list of minimum requirements:

1. The SAP Business One DI API (comes with your installation)
2. Microsoft Visual Studio Express (yes, the free downloadable version is all you need).
3. A modicum of programming skills in VB.NET or C# (maybe you have already dabbled in Excel macro development).
4. Any SAP Business One license that includes Indirect Access. (For example a single professional license and you are in business)

Yes, that’s all.

But, but…?

Sit down, take a deep breath, and think again about what it is that you actually require:

• Does it really need user interaction? If you can write down the decision making rules for your process (when, what, where, under what circumstances, under what conditions, etc), you can program it.
• Does it really need to happen at the exact time a user presses a button, or makes a choice? More often than not, business processes can be postponed or concentrated. For example, send your invoices any which way you like, the recipient is going to read them once a day at best, and probably the next day at the earliest. So does that EDI file really need to be created right now? And considering that that EDI file needs to be created and sent anyway, why give a user the chance to forget to press a button?
• More often than not, automation is meant to unburden users from laborious tasks, so why bother them at all? A so-called console application saved on the server, and activated by a server scheduled task, and Bob’s your uncle.
• You want to offer your users the possibility to create a sales order from an Excel file, and you want to enforce certain rules? Maybe you have tried the Stored Procedure approach. Then you know that it does not behave well / logically under all scenario’s. So you could fight the good fight with the UI API, and the antiquated mess that is the B1 client, or you can just open up Visual Studio, start a Windows project or even build a Web application, get the data you need directly from the database, show it with all the flags and colors your creative heart desires, enforce the craziest most complicated rules you like, and only in the end, if even necessary at all, reference the DI API to commit data back to the B1 database.

Here is an example. A screenshot of our warehouse control application. Top-left: orders that are being picked (using a web application run on PDAs, by the way). Bottom: open orders to be picked, and select-commit functionality. Right-top: statistics. How many open orders, and how many being picked, and the same for order rows. Middle-front: a separate window (shows when clicking an order number in the grid) showing a certain order’s relevant row details , including relevant user fields from the item master data. This window also controls a Siemens warehouse track logic.

Sorry if this sounds like I am patting myself on the back, although I do that gladly, it is not the purpose in this case.

My point is this: this window including all its functionality cost me roughly 80 hours to build (in between my other IT tasks). Of that time, 90 percent went into business logic, and track control, and maybe 10 percent into the GUI.

Point being, even though a professional software developer could probably program it faster, he/she could not get a 90% / 10% division of effort, if realized in the B1 client.

In conclusion

I hope this blog will save some of you from the perils of in-client automation and the self-chastisement that is developing with the UI API.