A Short History of the Accpac View Interface
In the beginning, there was the View. The View is a Sage ERP Accpac Business Logic object, for an introduction to Views see: https://smist08.wordpress.com/2010/09/11/accpac%e2%80%99s-business-logic/. The View is a Windows DLL with a set interface. Views expose a common set of functions, which are displayed below (this set of functions has grown over time):
There are functions to control the View, manipulate fields, get meta-data, manipulate records and manipulate sets of records. Each of these routines has a corresponding function inside the View DLL. In the early days all these functions were exported from the View DLL and theoretically could be called directly. However we never endorsed this, did it ourselves or provided instructions on how to do that. In a way calling these functions directly in the View DLL was the first View interface, even though it was never used. Not listed here is the real function that is called in the View DLL, namely rotoEntry. This function takes a structure as its argument that specifies the function to call and has some generic arguments that are used as the arguments to the various functions following a set convention. Again the users of Views have never loaded the View DLL and called the rotoEntry function directly.
You can call the Views by a couple of System Manager DLLs called Roto and RotoView. Roto is the low level object manager in Accpac, it handles the loading of View DLLs and figuring out things like what to load when Views are sub-classed. Roto also routes messages within Accpac to make sure the right View is called when a View call is made. RotoView is the first View interface that people actually used and is still in use today. Rotoview manages Roto to load the right View and provides convenient functions that correspond to the real functions inside all View DLLs. Below is a diagram showing RotoView and some of its functions using Roto to access a View through its rotoEntry routine.
RotoView provides an easy to use API for accessing Views, you just call viewLoad, viewOpen and then start doing real work. The Views still use this interface to directly talk to each other. All other interfaces talked about below also ultimately call the RotoView interface to do their real work.
One thing that was considered difficult when using the View interface is something called “View Composition” which is how you combine a number of low level Views into higher level objects. For instance to enter an order into O/E you need to use the order header view and order detail view together to enter the order. To use these they need to be composed together to make an order set of Views. This process can be a bit tricky so we wanted to hide it from users using macros. In the original version of CA-Accpac/2000, it shipped with a macro language called CA-BLE (Computer Associates Basic Language Engine). In the macro language we wanted to ability to call Views, but to hide some of the complexity, such as composing Views. The Icmd and cmd interfaces were intended to do this. The View compositions were specified in the Objects section of the application’s xx.ini file, and were done automatically for you. These interfaces were also used for the original import/export program used by our CA-Realizer based User Interface programs. This then led to the architecture of CA-Accpac/2000 1.0A as shown in the diagram below (Roto and RotoView are combined into Roto):
Icmd and cmd are nearly the same, Icmd is just a little lower level and is the actual interface used by the old import/export program. Some other programs used the cmd interface such as the data integrity checker program. Cmd/Icmd are still included with System Manager for any third party programs that might use them, but aren’t used by anything that Sage ships.
A weakness of all the APIs discussed so far is that they are only callable by a true Accpac SDK application launched from the Accpac Desktop. As we developed Accpac for Windows 3.0A we were developing the iConnect Server which needed to run independently on a server and not from the desktop. We were also getting complaints that it was hard to integrate Accpac to an existing standalone application, since you needed to develop an Accpac SDK part that would talk to the Views, the standalone non-SDK application couldn’t just call the Views directly itself.
And so was born XAPI. The main innovation in XAPI was that you first opened a session to Accpac providing basic sign-on information then went ahead and used the Views. This meant that anyone could use the XAPI interface whether they were an SDK application or not. So XAPI consists of some session management routines, then a set of routines very similar to what is in RotoView, except that they take the session as a parameter rather than the roto view handle used by RotoView. XAPI also contains routines to print reports and access other System Manager info easily. This way iConnect and non-SDK applications could fully integrate into Accpac. Later the iConnect program would be evolved into the Process Server, but both of these programs are long gone. The XAPI interface remains since it is used by many third party programs to interface to Accpac to this day.
This interface also stopped hiding the View compositions. We found that hiding compositions made it very hard to do some things with the CMD interfaces.
A further weakness of all the APIs mentioned so far is that they are all native DLL interfaces. These are easy to call from C programs, but problematic for other programming systems like Delphi or FoxPro. For Accpac version 4.0A we went 32-Bits and changed macro languages from CABLE to VBA. To integrate to VBA you need to provide a COM interface. So we could kill two birds with one stone, provide a COM interface to allow an easily usable interface for programming systems that have trouble calling DLLs directly and add VBA as Accpac’s macro language.
Advance to Accpac Advantage Series 5.0A. With this release we re-wrote our User Interface programs from CA-Realizer to Visual Basic (VB). To do this we needed a strong COM interface. Unfortunately you can’t just change an existing COM interface since it will break everything that uses it. So we made the decision to leave a4wcom alone and develop a version 2 COM interface for Accpac namely a4wcomex. This interface doesn’t go through XAPI, it goes directly to RotoView. It’s also designed so that it can be “remoted” meaning that it can be called over the Internet. This was then the basis for Accpac 5.x web deployed mode. See the diagrams below for how remoting is fit into our model (the top purple boxes are the typical components that make up a VB UI program). The AccpacCOMAPI below is really a4wcomex.
When talking to Views from a VB UI program, the VB code doesn’t talk directly to a4wcomex, instead the VB UI code talks to an ActiveX control called the DataSource control. The DataSource control then talks to the AccpacCOMAPI to perform the actual View operations. The reason we do this is that the DataSource is actually a visual control which means it can be configured at design time in the form designer. This means you specify which views to use and such in the form designer saving you writing quite a bit of code, most View compositions can also be specified this way. Another function of the DataSource is that it provides caching to reduce the number of View calls over the Internet when running in Web deployed mode.
With the Accpac Advantage Series 5.0A release we introduced Web Deployed mode where the UIs run as ActiveX controls inside the IE browser. With the original release we accomplished this by using DCOM in place of COM to do the View calls over the Internet. However this proved problematic, because DCOM is slow and DCOM uses random ports to communicate, which means it is very firewall unfriendly. You don’t know what ports it might use, so you have to leave them all open, which is very bad from a security point of View.
So with version 5.1A we added the option to use .Net Remoting as the communications protocol to talk over the Internet. To use .Net Remoting we needed to develop a .Net layer that sat over top of a4wcomex which we could then remote. Since we had to develop this layer anyway, we made it publicly available as another View interface for the added convenience of third party applications that were developing in .Net languages like C# or VB.Net.
If you have a .Net interface to something, then Microsoft through Visual Studio provides a tool that lets you expose that .Net interface externally as a SOAP web services interface. So when we developed the .Net interface, we got the SOAP interface for free.
However, you tend to get what you pay for, and like relying on DCOM to give you internet access for free over COM, it turned out to not work all that well.
With Version 6 we are removing the SOAP web service to be replaced by the much superior REST based SData web services interface.
So for Version 6 we’ve developed a native Java interface that is similar to the a4wcomex interface and talks to RotoView directly. The Java interface also has the distinction of being our first truly multi-threading interface. Multi-threaded programs could call our other interfaces, but would probably be blocked. The Java interface allows many threads to be running at once all doing work without overly blocking each other from operating.
SData is Accpac 6.x’s new REST base Web Services Interface. For more information on SData see https://smist08.wordpress.com/2009/11/24/sdata-in-sage-erp-accpac-6/, https://smist08.wordpress.com/2010/01/18/more-on-sdata-and-sage-erp-accpac-6/, https://smist08.wordpress.com/2010/02/14/stateful-sdata/ and http://sdata.sage.com/.
The way the SData interface works is we have a Java Server application (SDataServlet) that receives the SData webserver requests; it parses and processes these converting the SData web service requests into View calls which are made via the new Sage Accpac Java interface (SA-Java).