Stephen Smith's Blog

All things Sage 300…

Accpac’s Business Logic

with 17 comments

I thought I might spend a few blog postings talking about Sage ERP Accpac’s Business Logic. With all the talk about version 6’s new web based UIs, the Business Logic hasn’t been talked about much lately. However the Business Logic is still the heart and soul of Accpac. It contains all the difficult application logic that provides the true business value and ROI to the product. This blog posting will talk a bit about the architecture and an overview of Business Logic, then in future postings we’ll go into some of the details. Below is an architectural diagram of Accpac showing the Business Logic as the middle tier of a three tier architecture. The Business Logic talks to the Database layer through a database independent API layer (which we talked about here:

Then the various users of the Business Logic talk to it through a number of standard APIs that are part of the Accpac System Manager. Individual Business Logic objects are called Views (not to be confused with database views).

Encapsulates One Logical Entity and Its Operations

Each Accpac View encapsulates one logical entity and its operations. These entities are things like A/R Customer, G/L Accounts, O/E Order headers, etc. They don’t have to be physical objects, they can be abstract concepts like G/L Posting (the View that posts G/L batches). Even though these entities are very different, each and every View has exactly the same API. Within Accpac, rather than have a unique API for each object, where whenever you encounter a new object you need to learn a new API; every Business Logic Entity in Accpac has the same API. This means that if you learn how to do things with A/R Customers then you have also learned how to do the same things to A/P Vendors or G/L Accounts. This is also why there are many different types of APIs to access the Views. There is the .Net interface, two COM interfaces, several DLL interfaces and the forthcoming Java interface. Since the API is the same for every View, we just need to implement this interface in each technology which is reasonably easy to do.

Implemented as DLLs

Each View is implemented as a Windows DLL (or in our Linux port as a Linux Shared Object (SO)). These DLLs can be implemented in any language that can produce DLLs with the set of API functions that we specify. In the original CA-Accpac/2000 1.0B, G/L, A/R and A/P had their Views implemented in COBOL. Since then all our Views are written in C (sometimes with parts in C++). This is a fairly low level way to do things. It might be nice if we used a higher level language like Java, but then we couldn’t have our Views as DLLs. The benefit of DLLs (or SOs) is that they are the lowest level objects in the operating system and you can build anything on top of them. This is how we can have so many different APIs to access the Views, since anything has a mechanism to call DLLs, since you need to have this in order to talk to the operating system (which is just a set of DLLs (or SOs)). The Accpac SDK contains templates and tools to allow you to generate Views from tables that describe what the View needs to do. Then you fill in routines to code the real functionality. You can open multiple copies of the same View each with its own context, this way a View can be used in many ways at one time.

Standard Protocols

Views often don’t act in isolation. Often it takes the co-operation of several Views to accomplish a task. For instance there are two Views, one for the Order header and another for each detail line. For a given order there is one order header and then multiple details, each one for the purchase of an I/C Item or miscellaneous charge. To enter an order the order header and detail Views need to work together. They do this to ensure transactional integrity, multi-user correctness and that various totals are maintained correctly. To do this we have a set of View protocols. If you are entering documents through Header/Detail type Views then there are protocols that you need to follow. Following these well documented protocols (see the System Manager User Guide or SDK Programming Guide) will ensure things go smoothly. If you don’t follow the protocols than you will get strange errors and you transactions may be rejected. These protocols are followed to insert, update and delete documents.

Combine Logical and Physical Data

The lower level Views or Data Views are thin wrappers over various database tables. They expose the fields in the underlying table almost identically to what is documented in the data dictionary. A good many Views are of this type, exposing the physical data in the database. However they can also add some logical fields such as calculated fields, fields looked up from other Views (like perhaps a description for a G/L account) or anything else that will be useful to the user of this View. Sometimes you can set these logical fields to control how the View does calculations, such as setting whether you want taxes calculated automatically or you will manually enter them.

Avoids Duplication of Code

When a View needs data from a table that it doesn’t manager, it doesn’t just go to the database to get the data, it calls the View that manages that other table. This avoids duplication of code since the code for manipulating that object is in one place, namely its View. Then every View that needs that same data calls that View. In fact Views are the primary user of other Views and the majority of View calls are made by other Views rather than the external users of Views like macros or UIs. This also means the other Views can make use of all the logical fields added by the other Views as well as get at the physical data.

Maintain Database Integrity

Views are responsible for maintaining database integrity. We do not rely on the database server software to do this. Views will maintain field level integrity as data is put to the View records. If it’s something simple like a field needs to be upper case and the caller passed in lower case, it will simply convert the data to upper case as it comes in. This is to make the Views more resilient and friendlier to the View’s users. If it can simply fix data, it will. At the next level it will reject bad data, for instance if you enter an invalid currency code into a currency field, it will immediately reject it (actually there is a flag as to whether it immediately rejects it or waits for you to try to insert or update the record). At insert/update time the View will ensure there is record level integrity, any fields that need to be validated as a set together will be. It is also possible in a header/detail situation where data has to be cross validated across several records. This is all handled for you by the View. This is why we insist that anyone writing data into an Accpac company database, must do this through the Accpac Views. Writing data directly to the database through ODBC or ADO is very frowned on and can cause you to become unsupported.

Centralize Data Security

It might appear that Accpac controls data security through its UIs. This is because if you don’t have access to something then either an entire UI is hidden from you or if you don’t have access to a feature in a UI, then that feature is hidden. However the UI is asking the View if the person has access and then hiding the feature as an UI nicety. If the UI was badly behaved and didn’t hide the feature and tried to use that feature in the View then the View would reject it. This way security it maintained whether the data comes from an UI, a macro, import or from a third party application using one of our APIs.

Allow Distributed Application Architecture

Since the View API is well defined and contains a fixed set of functions for all Views, it allows us to easily serialize the calls. This is the process of taking the arguments for functions and putting them out as a serial set of bytes that can be transmitted over a communications link. This allows the caller to use an API that serializes the calls, sends the serialized stream over a communications link like the Internet, have the receiver interpret the serialized stream and make the View call. This enabled various remote APIs such as the old iConnect and Process Servers along with the newer DCOM and .Net protocols in use today. The new SData protocol works a bit differently since it is based on the standard REST protocol, which is already serialized as an URL and XML payload. This is translated into a number of View calls when received by the server.


Hopefully this gives an indication of some of the things Views do and they work. In future blog posts I’ll look at various aspects of the Views in more detail.

Written by smist08

September 11, 2010 at 8:14 pm

17 Responses

Subscribe to comments with RSS.

  1. stephen, your blog postings on Accpac are gold and provide a lot of information that is not generally available or easy to find in a concise place.

    Kerry Jones

    September 14, 2010 at 8:56 pm

  2. […] the View. The View is a Sage ERP Accpac Business Logic object, for an introduction to Views see: The View is a Windows DLL with a set interface. Views expose a common set of functions, which are […]

  3. […] records all API calls to the Accpac Views (Business Logic Objects). This includes all SDK produced applications whether from Sage or from […]

  4. […] For a bit more background on the Sage 300 business logic have a look at this blog posting. […]

  5. […] Views and then use the Views. For more general information on Sage 300 ERP’s Views have a look at this and […]

  6. […] to some degree you learn them all. For a bit more info on our Business Logic, have a look at this blog posting. For an example of creating Orders have a look at this […]

  7. Thank you Stephen, this helped a bunch.

    Romaine Carter

    June 13, 2013 at 5:21 pm

  8. Hi Steve,

    How are you,
    Hoping everything goes well.

    I am currently working on web project, in which i am opening accpac session and
    read the records from ARCUS, ARInvoice views. It works when i am running this web project
    from Visual Studio 2008, Windows 7 64. I ran the Visual Studio by Open as Administrator.

    But the sample application configured in the IIS and I browse this web application from
    IIS but accpac opening session and read the record views are not working.

    My environment details :
    Sage ERP 300
    Accpack Version 6.0
    Visual Studio 2008
    Windows 7 64bit.

    Thanks & Regards,


    July 6, 2013 at 7:29 am

    • Make sure for IIS that you are running your program in an 32-bit application pool. Also make sure the user IIS is running as has sufficient rights.


      July 6, 2013 at 3:40 pm

  9. Thank you Steve for you quick reply.

    However, am still having the same issue not sure where am going wrong. This is what i did based on your advise

    1. Application pool – Enabled the IIS application to 32-bit
    2. All windows users are given full control
    3. IIS was open as Administrator

    Please help

    Thanks again


    July 6, 2013 at 4:20 pm

  10. Steve,

    for more info. i have used COM API to connect Accpac and not .Net API.



    July 7, 2013 at 9:08 am

    • Have you checked the Windows Event log to see if it tells you anything? You could also try using AccpacSpy to see if anything is happening. You need to go to settings and switch to advanced mode and add background logging for the AccpacCOMAPI Session. If the DLLs won’t even load then nothing will be logged. Also check the IIS event logs to see if that is telling you anything.


      July 7, 2013 at 1:49 pm

  11. […] Last time we used the Sage 300 ERP .Net Interface to open a session and create a database link to a Sage 300 ERP company. In this article we will start to investigate how to use the API to manipulate the Sage 300 ERP business logic. The individual business logic objects are known as Views (not to be confused with the Views in MVC or SQL Server Views). For a bit more background on the Views have a look at this article. […]

  12. […] object repository, APIs and supporting services are implemented. I’ve blogged previously on our Business Logic Views. In this article I’m going to go into more detail on all the DLLs that provide the framework to […]

  13. […] application and use that to retrieve the data. In the case of Sage 300 ERP this involves using the business logic Views which we’ve discussed in quite a few blog […]

  14. […] Sage 300 ERP Views (Business Logic) give you a great deal of power to perform Accounting operations through our various APIs. However […]

  15. […] new architecture is based on using standard ASP.Net MVC along with re-using the standard Sage 300 Business Logic. Below is an architectural block diagram of the new components that sit on top of our traditional […]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: