Icertis using Windows Azure to handle workflows

Editor's note: Today's blog, written by Icertis chief technology Officer Monish Darda, describes how companies can use Windows Azure and SharePoint Online to provide scalable contract management and workflow services to customers.

Icertis Contract Cycle Management (CLM) provides business managers with services including: run, support, and periodic reporting of contracts. Contracts and their associated templates have highly managed entities and complex business processes that can run for months or even years.

We have some interesting requirements-not unique, but as a group, this is going to be an interesting challenge. Rely on a flexible deployment architecture to make SharePoint online and Windows Azure a mix and perfect deployment. Windows Azure is an inevitable decision-our customers want Microsoft's cloud products to expand their needs and be cost-effective. Icertis only need to do is to use Microsoft's cloud services to build enterprise solutions! Icertis's contract-cycle management software is a product built on the Windows Azure platform.

Determining deployment choices means that we need to design workflows in SharePoint (designer the user to design their own workflows in SharePoint, without writing code) and deploy workflows on Windows Azure. Running Windows Workflow Foundation on Windows Azure is a clear choice. A difficult question to answer is, how can complex things be run as required? The key to Workflow services in Windows Azure is:

, which runs on a support workflow, is highly scalable and available with more than 200,000 active contract workflow services, and a significant proportion of workflows are still being customized. Declaration, version-controlled workflows Enable persistent workflow instances with reliable Long-running workflow support (months or more)

We started thinking about workflows on Windows Azure. In this way, if necessary, we can choose to switch to another non cloud workflow engine and open the door to future managed Workflow Services.

(Picture 1)

The Contract lifecycle workflow is customized and stored in a XAML file format in the SQL Azure management and metabase. The infrastructure for using Windows Workflow Foundation (WF), workflow loading (blending), and programmatic execution are based on user actions or system events. A custom workflow runs with a worker role and uses SQL Azure as its persistent storage. Because it is a continuous run of workflow instances, the execution workflow worker role can be scaled up. By increasing the number of worker role instances at run time, you can work with concurrent workflow instances to provide flexible compute-intensive key components.

We write the workflow in the form of state machine workflow-the ideal metaphor of the life cycle of the contract. Custom activities provide a powerful but simple life cycle statement for a contract, and enterprise users can quickly relate to the state machine paradigm.

All right, that's it! We can quickly deploy and test workflows that we find very complex and difficult to implement. Some interesting monitoring code that allows dynamic expansion based on the execution characteristics of the currently running workflow. It turns out that this is more efficient and economical. We can demonstrate dynamic adjustments based on specific events (for example, at the end of this month, calendar event updates trigger thousands of contract expiration dates).

(Picture 2)

Computer Instance Select Workflow Service it turned out to be an interesting exercise. The Workflow service wants the computer to be memory intensive, so we try to use a different instance size for the changed workload. When the workload changes (mixed contract types represent different workloads), a medium instance of scaling provides greater flexibility (and therefore less cost) than larger instances and large instances. This exercise proves that the instance size selection affects the price, and the type of work is not only the number of instances needed to match, but also the size of the instance. For the workload, for Workflow services, to provide the best scaling costs, medium (dual-core, 3.5GB) computer instances can achieve the best results.

In our possession, there is now an extensible Workflow service that SharePoint teams can use to run some integration workflows that are not likely to run in the SharePoint Online sandbox environment. Of course, we also have our problems, especially in distributed transactions (not yet supported by SQL Azure, one day I intend to participate in this interesting topic), and we are all not around. What we expect to take months to run is done in a few weeks. This makes Windows Azure interesting: a bit of ready-made thinking can produce a huge payoff.

Here are some things we do to help improve service size and efficiency:

Windows Azure queues allow for a large number of responses and fewer resources by using queues to transfer long-running workflow activities to other services. Windows Azure caching uses the Windows Azure caching service to help workflows run faster without sacrificing data integrity and reducing database traffic. We use the 128 MB cache. The persistent storage area of the SQL Azure workflow allows us (using SQL Azure Reporting) to report on the execution and contract status of the workflow. Windows Azure Storage Table storage is our choice of audit events triggered by logs and workflow Services

The key points to note are:

Scalability of the

control. Workflows can be used as a mechanism for declaring and enabling extensibility for business processes that are kept simultaneously on Windows Azure. Separating the computer and memory-intensive tasks from the customer workflow activity can lead to better cost management of long-running workflows. Long-running computer-intensive workflows can take advantage of the inherent benefits of Windows Azure while preserving the benefits of declarative programming. Workflows can also be used to handle complex system integration challenges for computing instance selection. The choice of the size of a computer instance is a function of the workload, which eliminates the time difference between memory and computer requirements.

In short, it is a great and rewarding experience. And it deepens our belief that Windows Azure has the potential to be exploited by enterprise applications. It's good to be an early adopters and we look forward to sharing more practical experience with our customers to continue discovering the potential of Windows Azure.