3. Leveraging AX Business Logic

The post hopefully gives a good step by step description of how to invoke AX Business Logic to integrate AX and MSCRM together using Scribe.

As a foreword, this is a slightly longer post and so to aid clarity has been broken down into the following sections:

Introduction: CRM and ERP Processflow
Business Logic Integration
AX Business Logic implemented via X++ Methods
Invoking X++ to instruct AX to raise a Sales Invoice
Conclusion

Introduction: CRM and ERP Processflow

The key to any successful integration is to ensure that the two systems involved each leverage their own internal business logic or functionality to the best use of the overall solution and solution users.

For integrating MSCRM and AX this is a case of dividing which processes will happen within AX (such as Inventory Control, Sales Order Processing and Invoicing for example), which processes will happen within CRM (such as Sales Force Automation, Contact Management and Marketing) and which processes will overlap between the systems where different groups of business users may interact as part of the business process. (such as transferring an Order from the front-office Sales division of the business to the back-office for delivery)

This division of processes can be very different depending on the business involved – and particularly when using a large multi-purpose system such as AX which is capable of Resource Planning for a number of different business scenario’s through the various AX Modules.

The key here is using traditional models of Business Analysis to plot the solution business process to determine which departments or groups of users will be involved with each step of the process, and then work towards plotting the processes to a lower level to identify which users will operate within which systems and which areas of functionality. This then allows the complexity of the various systems to be ring-fenced to give a ‘plan’ for the solution in how the complexity will be used and managed.

To give an example of this when thinking about MSCRM and AX, an example Sales Process may function along the lines of the following diagram:

Example CRM ERP Processflow

An idea of how a processflow between Front-Office/CRM Processes and Back-Office/ERP Processes may be mapped out

This example process then plots that different functions take place with different teams (in this case most likely Sales and Finance) using different systems – such that the MSCRM Integration mode (link) is used to post a Sales Order from MSCRM to AX, and so from the front-office user to the back-office user:

ERP Process Diagram

Outline of process steps that may apply for the business process between the front-office and the back-office

This example process then plots that different functions take place with different teams (in this case most likely Sales and Finance) using different systems – such that the MSCRM Integration mode (link) is used to post a Sales Order from MSCRM to AX, and so from the front-office user to the back-office user

ERP Process Diagram

Outline of process steps that may apply for a back-office ERP user

This allows for the Finance User to leverage the AX Business Logic for processing the Sales Order based on the Sales Information originally taken within MSCRM by the Sales Team.

The Open Customer Invoice can then be synchronised back to MSCRM to allow the Sales Team visibility over the Invoice and the Payment Status of the Invoice.

This pattern of integration between MSCRM and AX can be mapped out and the tables/fields specified using a middle-ware tool such as Scribe to transfer the Order and Invoice data between the two systems.

However this type of integration is very data-driven in terms of how the Order is ‘posted’ from one group of users to another, where one group of users is using one system and the other group of users using the other. This transfers the data, but is not integrating the business logic of the two systems without manual effort being involved.

Business Logic Integration

In some cases, we may want a more sophisticated integration that allows a single group of users to invoke back-office logic directly from the front-office, such that AX Business Logic may be raised as a result of actions within MSCRM.

To take a simple example of this, say we had a business model that wanted to allow the Front-Office to raise an Invoice directly from an accepted Sales Order – we would not want the Front-Office team to switch between MSCRM and AX simply to raise the Invoice, and we could not allow an Invoice to be raised anywhere else except AX. (for reconciliation, tax rules and so on)

This would require that we provide a method that the Front-Office team could request to raise an Invoice and that this request would be automatically processed and the Invoice raised (if allowed) in AX. Such that our business process may resemble the following process diagram:

CRM and AX Processflow Diagram

Diagram showing the communication steps between CRM and AX for a front-office user

This process then removes the requirement for a back-office user to be involved in the process without removing the back-office business logic provided by AX, such that the front-office sales user interacts with CRM which then in turn interacts automatically with AX to pass business logic requests into AX, and then pass the resulting data back to CRM.

This can be done via using a middle-ware tool such as Scribe to implement the concept of Business Logic Integration as opposed to the traditional Data Integration – such that the integration invokes functions or methods within the Target System as opposed to merely sending data to the Target System.

(although when referring to Web Services, this could be taken as invoking business logic methods even if simply to send data to the Target System API but that is a topic for another time!)

AX Business Logic implemented via X++ Methods

In MSCRM we would typically develop additional business logic modules outside of the application itself using Visual Studio to write C# or VB classes and then register these modules as Plugins or Workflow Custom Actions using the MSCRM Plugin Registration Tool.

AX being a different application has a different framework for developing additional business logic as the development aspects are built into the core application via a custom development language and compiler that we can access from the AX Application itself. As this approach gives AX Developers a large scope for altering or extending the platforms functionality, this can become complex for inserting business logic to support our proposed CRM and AX Integration.

However we can minimise this complexity by focusing on adding simple methods into AX that carry out our business logic requirements without affecting new Data Types, Structures or User Interfaces in AX.

To implement these methods, we can add new methods written in AX’s native programming language X++. X++ is a language specific to AX that is very similar in syntax and operation to C++, which as the precursor to C# is not too alien a concept for the average MSCRM Developer.
We can access the AX Development area, known as the Application Object Tree, directly from the Dynamics AX Application either by clicking the AOT button or the Projects button.

AX Application Object Tree (AOT)

Screen showing the Application Object Tree within AX

However here the Scribe Adapter for integrating MSCRM into AX really comes into it’s own, as the existing template comes with a pre-built set of X++ methods to support the adapter’s initial integration template.

Scribe Actions class in the AX Application Object Tree

Screen showing the Scribe Adapter’s initial set of X++ Methods within the Development area of AX.

These X++ Methods can then be opened and the code examined to see or change the AX Business Logic that each method carries out:

AddSalesLineExecute Method in the ScribeActions area of the AX Application Object Tree

Screen showing the ‘AddSalesLineExecute’ X++ method being edited within the Development area of AX

With the X++ code for these methods present, the Scribe Adaptor gives us a simple area in AX that we can refresh which of these methods we may want to invoke via the Scribe Workbench for our integration routines.

Scribe area in AX

Screen showing the Scribe area created by importing the Scribe Template XPO into the AX Deployment

There are a few useful folders inside this Scribe area which are detailed further within the adapter documentation, however for making the X++ methods available we need to look into the Scribe Executions folder.

ScribeExecutions screen in the AX Scribe area

Screen showing the Scribe Executions folder listing various X++ Methods that may be enabled for use in integration routines.

Here we can use the Refresh button and the enabled tickbox to specify which of the X++ Methods within the ScribeActions area of the Application Object Tree will be visible for use in the Scribe Workbench.

This then allows us to invoke these methods within the Scribe Workbench as any other Adapter Object/Stored Procedure within Scribe:

Scribe Workbench listing possible AX Stored Procedures

Screen showing the possible selection of AX Stored Procedures within Scribe when using the AX Adapter as the Target as part of a Scribe DTS Script.

This then allows the AX X++ Method to be invoked as any other Scribe Target.

Scribe Workbench showing CRM Order to AX Order invoking the AddSalesLineExecute method in AX

Screen showing the ‘AddSalesLineExecute’ X++ method used as a Target Step within a Scribe DTS Script.

We can then incorporate this Stored Procedure/X++ Method Step as part of our integration DTS routines alongside the other Data Integration Steps for when we need to prompt business logic within AX as a result of MSCRM, as opposed to purely bringing across target data.

Whilst requiring an understanding of AX X++ which in turn requires a good understanding of the AX Data Model, this is a very powerful and relatively simple method for truly integrating MSCRM and AX to best effect.

In an ideal world or for larger projects, the best division here for a trained AX Consultant to develop the required X++ Methods as ‘AX-Specific’ requirements as analysed by the project’s Business Analyst or Functional Consultant – alongside a trained MSCRM Consultant and/or Data Integration specialist to implement the MSCRM and Integration requirements. In this fashion, the individual systems involved are managed via the individual system specialists to produce the overall solution as the Project’s product.

For smaller projects however, this could be centralised to a single Consultant or developer who is comfortable with the MSCRM, Scribe and AX concepts and development.

To illustrate this concept further and bring this (fairly long!) post to a close, we will last look at a practical example of this technique involving some simple X++ invoked as a result of MSCRM via Scribe.

Invoking X++ to instruct AX to raise a Sales Invoice

Going back to the original discussion in this post, a good example of where we would need to leverage AX’s business logic is the ability to raise an Invoice. Invoices in AX are a complex area involving many different Database Tables and the logic to raise an Invoice must look at the different Business Rules within the AX Deployment as well as Sales Tax Rules for the calculation of Tax depending on the Product and National Tax Laws involved.

In this context a pure Data Integration for raising a new Invoice in AX would be impossible, and so we would need to invoke proper AX Business Logic via X++ to have Scribe automatically instruct AX to raise an Invoice as a result of a certain action in MSCRM.

Fortunately the X++ code to do this is actually very simple, so our first step is to create a new Method in the ScribeActions area to do this:

/// <summary>
/// Instructs AX to raise an Invoice for a particular Sales Order
/// </summary>
/// <parm name="parm1">The AX Sales Id of the Sales Order to raise an Invoice for</parm>
/// <remarks>
/// </remarks>
static void TestExecute(str parm1)
{
    salesId                 salesId;
    SalesTable              salesTable;
    SalesFormLetter         salesFormLetter;
    ;

    salesId = parm1;
    select firstonly salesTable where salesTable.SalesId == salesId;
    if(salesTable)
    {
        ttsBegin;

        // Get a new instance of SalesFormletter
        salesFormLetter = SalesFormLetter::construct(DocumentStatus::Invoice);

        salesFormLetter.update(salesTable, SystemDateGet(), SalesUpdate::All, AccountOrder::None, false, false);

        ttsCommit;
    }
    else
    {
        throw error(strfmt("Sales order %1 doesn't exist", parm1));
    }
}

With the X++ for this method in place, we can then Compile and Save the method before then refreshing the Scribe Executions table that we saw earlier to then make sure that this method is in place and enabled.

TestExecuteMethod in AX

Screen showing saving and compiling a Test Execute method to raise a new Invoice in AX for a particular AX Sales Order.

We can then use a Scribe Integration Process to pick up on a certain Event in MSCRM that we want to trigger an Invoice in AX.

Instruct AX to post an Invoice from an Order in MSCRM

Screen showing an Order in MSCRM that is synchronised with a AX Sales Order via the shared CRM GUID Id and the AX Sales Id fields.

Open Sales Order synchronised from MSCRM to AX

Screen showing the corresponding Open Sales Order in AX

Here we have a Sales Order shared between CRM and AX as an Open Order with a ‘Post Invoice to AX’ flag, we can then configure a Scribe Integration Process to wait until this flag is ticked and then run a DTS to invoice the corresponding Sales Order in AX.

Scribe DTS to instruct AX to raise a new Invoice for a particular Sales Order

Screen showing the Scribe DTS intended to be invoked by a corresponding Scribe Integration Process as a result of the ‘Post Invoice to AX’ field being flagged in MSCRM – with the DTS invoking the earlier ‘TestExecute’ AX Method to raise an Invoice against the AX Sales Order indicated by the Param1 input parameter.

So by triggering this prompting event (which could be a simple field as the screens here, or an update to the Status code field in MSCRM) will then send a message through Scribe which will in turn invoke the DTS Step to execute the indicated X++ and so leverage the AX Business Logic for raising the Invoice. Such that refreshing the Sales Order in AX shows that the Order has now being updated to the Document Status of ‘Invoiced’:

Invoiced Sales Order in AX

Screen showing the AX Sales Order being updated to Invoiced

Open Customer Invoice in AX

Screen showing the resulting Open Customer Invoice in AX

This then has our raised Invoice in AX as a result of the Front-office user instructing the back-office system to raise an invoice without direct interaction with the back-office system as a consequence of our integration leveraging the AX Business Logic through Scribe to raise the invoice.

To ensure a full user experience for the Front-office user we could then use similar methods through the Scribe Adapter to pass the new AX Invoice back to CRM to make the user aware that the Order has now been Invoiced, the payment amount now pending against the Customer Account and the Invoice Number.

Invoiced Sales Order in MSCRM

Screen showing the Order now updated to Invoiced in CRM – with the ‘Post Invoice to AX’ flag now unticked as this operation has finished and to give the option that the Order may be changed and so need to be reinvoiced.

Invoice details in MSCRM as a result of pass-back from AX

Screen showing the Invoice passed back from AX to CRM to show the Invoice Number and Amount in CRM to the front-office user.

This then fully allows the front-office user to raise and view Invoices purely in CRM as their front-office system based on the back-office business logic in AX to implement the business process flow we identified in the earlier diagram.

This is one possible use for using the Scribe Adapter to integrate MSCRM and AX in a process-driven fashion, allowing us to take the default Adapter template and customise this to fit a client’s intended business process for connecting their front-office Sales and Marketing functions into their back-office Accounts and Financial management.

Given the ability to leverage the Business Logic in AX, this could then be extended to use the AX Payment Methods for the Sales Order and Invoice to automatically settle the Invoice for Point of Sale Ordering which can be a useful extension for Internet or Cash sales. The following excellent AX-related post by Craig Griffith details how to configure this type of Payment Method in AX, which the Scribe Logic for integrating Orders from MSCRM to AX can then make use of.

Ignify: How to create Cash Sales in Microsoft Dynamics AX 2009

Conclusion

This then gives us a set of technical methods through the use of the Scribe Adapter and Integration Processes to integrate different areas of MSCRM and AX together to build a full solution for the client’s business model.

I think this is an interesting area for CRM and ERP systems to go in the future as more and more of my clients are looking for fully integrated solutions across the traditional Front-Office and Back-Office divides, and these solutions are now (through Scribe and the Dynamics Range coming together) becoming more realistic to building real business benefits and efficiencies.

In continuing with this direction, I can see the Dynamics Range can increase their value to businesses as this concept of true CRM and ERP integration is still quite rare across the various systems and packages involved. I believe Netsuite is one of the few complete packages to have both sets of front and back-office operations in a single software system, for others such as Salesforce, SAP, SAGE, GP and NAV this integration step is crucial for a single solution.

Quite long article ranging between Business Process Consultancy and some quite technical concepts between MSCRM and AX, so thank you for making it this far if you’ve read right through! Hopefully some of the information here will be useful when thinking about putting MSCRM and AX together.

Am coming across more projects involving both AX and MSCRM over the last 6 months, so hopefully I will have chance to come back and expand on this in the near future.

2 Responses to 3. Leveraging AX Business Logic

  1. Pingback: MSCRM and AX: Leveraging AX Business Logic from MSCRM | CRM Consultancy Blog

  2. Pingback: Business logic process

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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