Recently, I have been involved into a project aiming to upgrade the existing B2B webshop of a multinational trading company into an off-the-shelf, standardized e-commerce solution. 

The existing application was connected to Microsoft Dynamics AX as a background ERP, and was built as a customized Dynamics Enterprise Portal. The solution had been developed in-house and they spent about 4 years to implement the functional requirements raised by the subsidiaries and also to overcome the emerged performance and stability issues. The final solution had more or less complied with the company needs, however some major issues remained that could not win through:

- Windows authentication: due to its nature Enterprise Portal is not capable to support other than Windows authentication

- Rigid UI: Sharepoint 2010 has a table based, strict layout, which is very hard to alter

- no responsiveness

- SEO compatible URLs are not available in Sharepoint, also IIS rules provide very limited support

- closely coupled with Dynamics AX

The new, standard webshop is built on Apache/Tomcat and is written mainly in Java. As it needs to connect with Microsoft Dynamics AX native connection is impossible. It is of no problem however, as decoupling is the preferred way.

So, here comes the question, how to connect / integrate systems with so different roots. Here are some of the ideas that popped up:

- Configure Dynamics AX Document Exchange interface, within the Application Integration Framework - AIF, to operate in webservice mode,

- Setup a Microsoft BizTalk server (which provides enterprise application integration) that can directly connect to AIF and provides web services to the outside applications like the contracted webshop,

- Implement complex calculations (like price inquery) within the standard webshop, i.e. duplicate the same algorithm that Dynamics AX is performing

- Implement classic ASP.NET webservice methods that invoke Dynamics AX business logic via the .NET Business Connector, 

 

Here are the results of the short investigation with the above approaches:

- though AIF can be configured for Dynamics AX 2009 in such a way to operate like a webservice, only Query objects can be invoked, the response data is tabular (in XML format) and implies tremendous class instantiation and XML serialization

- setting up BizTalk and thus connecting to AIF makes the solution even more complex and certainly slower

- duplicating complex business logic is a high risk to any company, luckily it has ruled out quickly

- implementing ASP.NET webservice methods that access Dynamics AX via .NET Business Connector can be done quickly and it works like a charm.

 

Quite some companies are extending their AX2009 ERP application with e-commerce solutions for enhancing their sales activities. The traditional way of integrating AX with external applications is done either via Document Services or via the .NET Business Connector.

However, the Document Services support is limited only to file based exchange (usually XML) in AX 2009, i.e. communication is realized off-line (Though, starting from AX2012 it is possible to promote business logic via web services employing Microsoft's WCF framework). From now on by AX I mean AX 2009 throughout the article.

When exchanging data via XML files, the AX application is configured to expose sales related data on a regular basis. These data incorporates product-, customer- and price related information just to mention a few. This information is then loaded to the external e-commerce application to make it available to the end user (which is usually a customer in a B2B scenario). As the majority of the customers in such a system is having a specific trade agreement for each product and product groups, the number of product - customer combinations is extremly high. This makes a burden on computing customer specific prices especially when listing and searching for products in the e-commerce applications. 

Furthermore, there might be other price influencing factors as well, such as discounts applicable when ordering above a certain limit, service discount for orders via the web, etc. Also additional costs and charges might be applied, like transportation, environment protection (green care) fees, which all needs to applied and often presented to the user. 

As such, it all requires a complex calculation on a per product and also on a per order level. The details of this calculation is implemented in the background AX application, and it is not advisible to mirror the same logic in the e-commerce system as it requires all specific trade agreements to be transferred, which is obviously business critical data. On the other hand it results in redundant logic which is hard to maintain when it comes to changes in the calculation process.

As a consequence when integrating in off-line mode (ie. via XML document exchange), the exposed functionality is very limited by nature. Often, only public prices can be shown, which means the e-commerce application must be degraded into a simple sales portal. For companies aiming to have a full-fledged solution where the information presented to the customer is fine-grained, only an on-line approach can be successful. It can be achieved by employing the .NET Business Connector which allows access not only to data stored in AX but to the business logic as well. 

When implementing web services accessing AX business logic, the displayed data is 100% correct and relevant to the customer. However, this approach has its barriers too: the solution is closely coupled with AX, which results in performance penalties when it comes to huge loads on the AX system. This can be enhanced by introducing e-commerce specific clusters in the AX server (AOS) park. 

Therefore decision makers should carefully focus on what is the exact need of their company. When a B2B command is critical then a closely coupled solution is a better choice, as the information displayed is better tailored to the customer. When it comes to B2C solutions, information can be exposed by way of documents, but still the information presented is very limited resulting in a more generalized application.

 

About Us

Who we are

Follow Us

Facebook
Twitter
Google+

Mailing List

Subscribe to our mailing list.

Contact Us

Call: +36 30 394 7324
Email: info@ecommerce4ax.com