Stephen Smith's Blog

Musings on Machine Learning…

Posts Tagged ‘web applications

Multi-Threading in Sage 300

with 6 comments

Introduction

In the early days of computing you could only run one program at a time on a PC. This meant if you wanted to run 10 programs at once you needed 10 computers. Then bit by bit multitasking made its way from mainframes and Unix to PCs, which allowed you to run quite a few programs at a time. Doing this meant you could run all 10 programs on one computer and this worked quite well. However it was still quite a high overhead since each program used a lot of memory and switching between them wasn’t all that fast. This lead to the idea of multi-threading where you ran very light weight tasks inside a single program. These used the same memory and resources as the program they were running in, so switching between them was very quick and the resources used adding more threads was very minimal.

Enter the Web

Think about how this affects you if you are building a web server. You want to basically run your programs on the web server and consider if you are running in the cloud. If you were single process then each web user running your app would have a separate VM to handle his requests and he would interact with that VM. There would be a load balancer that routes the users requests to the appropriate VM. This is quite an expensive way to run since you typically pay quite a bit a month for each VM. You might be surprised to learn that there are quite a few web applications that run this way. The reason they do this is for greater security since in this model each user is completely separated from each other since they are really running against separate machines.

The next level is to have the web server start a separate process to handle the requests for a given user. Basically when a new user signs on, a new process is started and all his requests are routed to this process. This model is typically used by applications that don’t want to support multi-threading or have other concerns. Again quite a few web applications run this way, but due to the high resource overhead of each process, you can only run at best a hundred or so users per server. Much better than one per VM, but still for the number of customers companies want to use their web site, this is quite expensive.

The next level of efficiency is to have each new user that signs on, just start a new thread. This is then way less overhead since you use only a small amount of thread local storage and switching between running threads is very quick. Now we are getting into have thousands of active users running off each web server.

tangled_threads_small1

This isn’t the whole story. The next step is to make your application stateless. This means that rather than each user getting their own thread, we put all the threads in a common pool. Then when a request for a user comes in, we just use a free thread from the pool to process the request. This way we don’t keep any state on the server for each user, and we only need the number of threads to be able to handle the number of active requests at a given time. This means while a user is thinking or reading a response, they are using no server resources. This is how you get a web applications like Facebook that can handle billions of users (of course they still use tens of thousands of servers to do this).

These techniques aren’t only done in the operating system software, but modern hardware architectures have been optimized for these techniques as well. Modern server CPUs have multiple cores which are very efficient at running multiple threads in parallel. To really take advantage of the power of these processors you really need to be a multi-threaded application.

Sage 300 ERP

As Sage 300 moves to the cloud, we have the same concerns. We’ve been properly multi-process since our 32-Bit version, back in the version 4 days (the 16-Bit version wasn’t really multi-process because 16-Bit Windows wasn’t properly multi-process).

We laid the foundations for multi-threaded operation in version 5.6A and then fully used it starting with version 6.0A for the Portal and Quote to Orders. Since then we’ve been improving our multi-threading as it is a very foundational component to being able to utilize our Business Logic Views from Web Applications.

If you look at a general text book on multi-threading it looks quite difficult since you are having to be very careful to protect the right memory at the right time. However a lot of times these books are looking at highly efficient parallel algorithms. Whereas we want a thread to handle a specific request for a specific user to completion. We never use multiple threads to handle a single request.

From an API point of view this means each thread has its own .Net session object and its own set of open Sage 300 Business Logic Views. We keep these cached in a pool to be checked out, but we never have more than one thread operating on one of these at a time. This then greatly simplifies how our multi-threading support needs to work.

If you’ve ever programmed our Business Logic Views, they have had the idea of being multi-threaded built into them from day 1. For instance all variables that need to be kept from call to call are stored associated with the view handle. There are no global variables in these Views. Further since even single threaded programs open multiple copies of the Views and use the recursively, a lot of this support has been fully tested since it’s required for these cases as well.

For version 5.6A we had to ensure that our API had thread safe alternatives for every API and that any API that wasn’t thread safe was deprecated. The sort of thing that causes threading problems is if an API function say just returns TRUE or FALSE on whether it succeeds and then if you want to know the real reason you need to check a global variable for the last error return code. The regular C runtime has a number of functions of this nature and we used to do this for our BCD processing. Alternatives to these functions were added to just return the error code. The reason the global variable is bad, is that another thread could call one of these functions and reset this variable in between you getting the failed response and then checking the variable.

State

If you’ve worked with our Views you will know that they are quite state-full. We can operate statelessly for simple operations like basic CRUD operations on simple objects. However for complicated data entry (like Order Entry or Invoice Entry) we do need to keep state while the user interacts with the document. This means we aren’t 100% stateless at this point, but our hope is that as we move forwards we can work to reduce the amount of state we keep, or reduce the number of interactions that require keeping state.

Testing Challenges

Fortunately testing tools are getting better and better. We can test using the Visual Studio Load Tester as well as using JMeter. Using these tools we can uncover various resource leaks, memory problems and deadlocks which occur when multiple threads go wrong. Static code analysis tools and good old fashioned code reviews are very useful in this regard as well.

Summary

As we progress the technology behind Sage 300, we need to make sure it has the foundations to run as a modern web application and our multi-threading support is key to this endeavor.

 

Advertisements

Written by smist08

February 22, 2014 at 5:37 pm

Sage Billing and Payments

with 12 comments

Introduction

Sage Billing and Payments is one of the three web/mobile applications that was shown as a POC (Proof of Concept) at last year’s Summit conference and then released at this year’s Summit conference. Sage Billing and Payment is strictly a Web application, and although it will run as a Web application on mobile devices, doesn’t have a mobile native component.

Sage Billing and Payments is meant to help improve the collection of Accounts Receivable. It provides a mechanism to e-mail people their invoices and then to collect their money via credit card. The application has mechanisms to customize all your client communications.

Last week we looked at Sage Mobile Service where technicians performed billable work. If they took payment by credit card, then they are paid, but if they took payment on account, then this application is to help collect that money.

Walk Through

To use this application you go to its URL in your favorite browser and sign-on with SageID. This then leads you to the following dashboard/home screen.

sbp1

This page gives you information on the invoices that need to be processed and how many people are paying their invoices.

Within the application there is a great deal of functionality around customizing your communications. There are a number of templates for invoices and receipts. You can select one of the existing ones from this page.

sbp2

If this suites your needs you can go ahead and use it and if it doesn’t then you can select it and then edit it to further customize it.

When you choose to customize it you go into a visual HTML editor where you can create an invoice to match your companies branding and communications policies.

sbp4

Once everything is setup, you can go into customers to manage contacts and manage their receivables.

sbp3

From this page you can send or print any invoice. As well as review their invoices and payment history.

From here you can also mark whether to just send invoices and payment receipts to the customer automatically (you can also do this for all the customers in settings). Generally this is much more efficient than going through all the customers and manually triggering the e-mails.

When a customer receives and invoice there is a link which will take them into their browser and go to a customized payment website where they can pay their bill instantly by credit card. Of course this site they go to is completely customizable and one is shown below.

sbp5

Why Not Do This in ERP?

To some degree you can do all this in your ERP system, so why would you want to subscribe to this Web service? Basically this service is designed to address a number of pain points people have performing this work from within their on-premise ERP system:

  • Integrating to e-mail to e-mail invoices is hard to setup and operate. In their efforts to fight spam, Microsoft has made it harder and harder for programs to send out automated e-mails. Outlook will popup a messagebox whenever any program accesses the address book or attempts to send an e-mail. Supporting all the various e-mail systems out there is hard and tends to concentrate on Exchange.
  • Performing customization to invoices and receipts in Crystal Reports is hard. Often you have to hire a Business Partner to make any changes to your custom invoices.
  • Automatically collecting payment via credit card right out of the e-mail isn’t supported.

Basically this solution is meant to make the whole process much easier and much more effective. Dealing with e-mail systems becomes our problem. The pages to edit and customize all the forms in this offering are far simpler than dealing with Crystal Reports. Then there is the integration to Sage Payment Solutions for credit card processing right out of the e-mails via a web site that we host.

Technology

This solution is hosted in the Microsoft Azure cloud. It uses the Sage Data Cloud to store information and communicates back to the on-premise ERP application via a connector that is installed there. The actual web application is written in ASP.Net MVC and is deployed to Azure using PaaS Web and Worker roles. We use Telerik’s Kendo UI for our grid controls. This is a nice UI library of HTML/JavaScript controls that provide a very nice rich client user experience in the web. Another tools we find really helpful is JetBrain’s Resharper. This tool adds a lot of advanced refactoring and static code analysis functionality to Visual Studio that we missed from Eclipse. For source control management we use Git on GitHub. To perform continuous integration and to manager deployments to the various web sites (development, staging, production, etc.) we use JetBrain’s TeamCity. This is integrated to our GitHub source control repository and can build as the source code changes and continuously run automated tests. Then we can push a branch out to an Azure subscription whenever we want.

Like most web sites we have put in place the infrastructure to update the site fairly regularly so we can immediately address problems and can add features and functionality on a frequent basis.

The data is stored in a multi-tenant Azure SQL database as part of the Sage Data Cloud. This data cloud is shared by other mobile and web applications like Sage Mobile Service. This way your data isn’t duplicated to the cloud for every service you subscribe to.

The ERP connector is the same one used by Sage Mobile Service and is available currently for Sage 100 ERP and Sage 300 ERP with a version for Sage 50 ERP (Canadian and US) to follow shortly.

Summary

Sage Billing and Payments is a web application that is connected to your on-premise ERP system to help you more efficiently collect money from your customers. It relieves you of the pain of accepting payments over the phone, managing email system integrations and performing difficult Crystal customizations.