Microsoft Dynamics Center of Excellence

Dynamics CRM Performance Optimization II. (Anamnesis)

2013-03-18T15:05:01Z

Dynamics CRM Performance Optimization Blog Series

Introduction
Anamnesis
Diagnosis
Therapy
Control Examination

Anamnesis

As I explained in the previous post, the purpose of the "Anamnesis" phase of a Dynamics CRM performance optimization engagement is to understand the essence of the performance complaints. Based on a detailed understanding we can follow with the right diagnosis of the problem. So what does it mean "understanding"? In order to understand, you must do following:

Talk to the customer
Verify the complaints in a hands-on experience

We need to talk to our primary customer contact person, but also to the end users from whom the complaints are coming. We need to see the behavior directly on the computers, where it happens. If the poor performance is observed only on remote locations we need to ask the customer to demonstrate it using whatever technology available – conference call, remote access to the computers etc. Further, it is essential to understand if the behavior is role-specific / user-specific and if yes, what the characteristics of the roles or users having performance issues are.

At the end of this "anamnesis" exercise, we will have a list of different findings typically falling in one of following 2 major categories:

User Interface (visible) issues
Backend processing issues

In the following part I will give you an overview of typical performance issues from both categories which should be considered as an guidance for subsequent engagement phases:

User Interface (visible) issues

In the following table I will present you the most typical user interface performance issues:

Issue	Description	Conditions
Overall poor performance	This is a very generic issue and must be further analyzed if it can fall into other – more specific category	All users? Selected user groups?
Entity form slow load time	This is definitely the number one in all hit-lists and the most frequently complained performance issue of all. The reason for this is, that loading of entity forms is something, the users do most of the time and the expectation for good performance is very high.	All users? All entity forms? Selected users groups? Selected forms?
Entity form slow save time	Slow saving time is less frequent due to some specific implementation reasons, but also due to lower performance expectations (Broadly accepted expectation is, that saving does "something" in the background and needs some time for that)	All users? All entity forms? Selected users groups? Selected entity forms?
Entity view slow retrieval / Advanced find slow retrieval	If this issue occurs we can observe following: - A waiting time before the view rendering starts - The view rendering runs slower than expected	All users? All entity views? Selected users groups? Selected entity views?
Slow rendering of reports	Typically rendering of reports should not be much slower than a couple of seconds. Everything above is recognized as an issue	All users? All reports? Selected users groups? Selected reports?
Slow rendering of dashboards	Dashboards are composite UI constructions, so a longer rendering time can be expected, but if some of the dashboard elements are rendering too slowly the whole user experience suffers.	All users? All dashboards? Selected users groups? Selected dashboards?
Outlook client starting slowly / freezing	In most of the Dynamics CRM implementations the Outlook Client is the preferred client-side solution thanks to the synchronization function and offline capability. It is very annoying if users observe significantly lower Outlook performance or even freezing issues after installing the Dynamics CRM client.	All users? Selected user groups? Dependency on Outlook version?
Slow SharePoint integration	Typically SharePoint folders integrated on Dynamics CRM forms should not render much slower than any other usual sub-grid.	All users? On all entity forms? Selected users groups? On selected entity forms?

Backend processing issues

In the following table I will present you the most typical backend performance issues:

Issue	Description	Conditions
Slow workflow execution	Dynamics CRM users typically expect, that the workflow triggered by a user interaction is executed latest "in a couple of minutes". Anything between "more" than a couple of minutes and hours/days may be a serious issue, especially when business processes depend on finished workflows.	All users? Selected user groups? All workflows? Selected workflows?
Slow incoming data integration	Almost every large Dynamics CRM implementation contains a large portion of integration with surrounding systems. Incoming integration is mostly implemented as: - Real-time - Batch In both cases users expect the data to be in Dynamics CRM "in time", when they need them.	All data? Selected data?
Slow outgoing data integration	The outgoing integration is mostly implemented as real-time, so the user's expectation is the same as in previous.	All data? Selected data?
Slow server-side E-Mail integration	If server-side integration with a messaging system is implemented, users expect same behavior for Dynamics CRM E-Mail activities as for E-Mails themselves – very fast sending out or delivery.	All E-Mails? Sending only? Receiving only?
Slow initial data load	This is a very specific issue, which does not directly touch end users, but rather the implementation team and is a one-time issue. But never then less, it can be a major show-stopper, especially if a prescribed time slot is given to the implementation team to import huge amounts of initial data.

In the next part I will start the most interesting topics around diagnosing the reasons for poor performance, so stay tuned!

Robert Rybaric is an architect in the Microsoft EMEA Dynamics Center of Excellence

Dynamics CRM Performance Optimization I. (Introduction)

2013-03-09T08:34:21Z

A good performance of a Dynamics CRM solution is one of the key success factors of a successful implementation. Well, I assume no one will argue with this statement, but what does it exactly mean a good performance of a Dynamics CRM solution and how to optimize a solution which is supposed to perform poorly? Exactly these questions I will try to answer in a blog series which starts with this first article. I was thinking for a longer time about a suitable analogy from our everyday's life and hope to found one: a Dynamics CRM performance optimization is like a doctor's treatment of a sick patient. Sounds weird? Well, actually it isn't, as you will see in this and a couple of next articles. Here is the planned table of content of the blog series:

Dynamics CRM Performance Optimization Blog Series

Introduction
Anamnesis
Diagnosis
Therapy
Control Examination

First I would try to explain on a high level how does a way from an unsatisfied customer complaining about "poor performance" to a happy one look like. For this I will use the doctor's analogy from the very beginning.

Anamnesis

The purpose of the "Anamnesis" phase of a performance optimization engagement is to UNDERSTAND. "Poor performance" is obviously too broad, personal and subjective to be able to give any advisory before the problem is understood. As you will see in the next article, it can be everything between the most typical entity form load time and very specific issues like the integrated SharePoint document management solution is slow, or the Outlook client starts slowly and freezes. I will present you an overview of most common (and less common as well) performance issues, how to categorize and prioritize them and what are the best ways to start diagnosing them.

Diagnosis

After we have fully understood the problem it is necessary to find the cause, or more typically the causes, as it is not realistic to expect that a poor performance of a Dynamics CRM solution is caused by one single reason. In other words it is never the "magic button" which just needs to be pressed and everything is solved and everyone is happy. In this phase we need deep understanding of the products involved in the solution as well a good toolset to analyze possible performance bottlenecks. I will present you the diagnosis methods, tools and metrics and how to document the findings in a meaningful way. It is not uncommon that this phase can lead to finger-pointing and so a rock-solid documentation is crucial.

Therapy

Great, problem understood, causes identified and the therapy can begin. Is it really so simple? Unfortunately not. Like in medicine, we have simple performance issues as well as very hard, which cannot be solved by taking Aspirin for a week. But the good news – every Dynamics CRM solution can be performance optimized with the right therapy, just the therapy can be sometimes longer and more expensive. I will show you how to create a "therapy plan", in other words a set of performance optimization recommendations with respect to the customer's individual situation and constraints and cost/value benefits. After the "therapy plan" was presented to the customer, the immediate performance optimization engagement ends. But a good doctor will always see the success of his therapy so a regular contact with the customer in form of "control examinations" is absolutely necessary.

Control Examination

A doctor is always just an advisor to his patient – in a good hope the patient is willing to follow his advisory. Same applies for a Dynamics CRM performance optimization engagement. The therapy is a set of optimization recommendations and the success depends on the customer's willingness to implement the recommendations. In this article I will show you how to best accompany the customer along the way of implementing the performance optimization recommendations, how to measure the improvements and document the success of the engagement.

Robert Rybaric is an architect in the Microsoft EMEA Dynamics Center of Excellence

Understanding the data flow process between AX and eCommerce

2013-03-08T17:20:00Z

In a previous post I walked through how to make changes to your online web catalog directly from Dynamics AX 2012 (http://blogs.msdn.com/b/dynamics-coe/archive/2013/02/04/updating-your-commerce-catalog-directly-from-dynamics-ax.aspx). This powerful feature showcases the truly integrated, omni-channel retail solution that is Dynamics AX. In this post, I'm going to look at what's happening in the background and walk through the data flow of this process.

So to begin, let's have a look at a very simple picture representation of some of the components involved in this process. (and yes there are a number of elements involved that I've left off but this will get us started).

So let's step through what's happening when we publish our catalog to the web.

Step 1: Publishing the catalog from Dynamics AX to the Commerce Run Time database

When you publish the catalog in Dynamics AX and run the A-1075_OC job, the CRT Synch Service takes channel and catalog data from the Dynamics AX database and puts it into our Common Run Time (CRT) database. [In our demonstration image, this database is the AXRetailSP database]. The CRT database is created as part of the Dynamics AX Retail Commerce setup. It can be thought of as another store in the AX for Retail framework, in this case, an online store. It contains data for use by the CRT engine, including products and product hierarchy. For example, in the CRT database, there are the tables ECORESCATEGORY and ECORESPRODUCT (for those who know the Dynamics AX schema they should look familiar). There are also additional tables in there which support other functions such as publishing information, but that's a subject for another day. In short, when you've got data into the CRT DB, you're well on your way.

Step 2: Loading (Publishing) the SharePoint Authoring Site

The AX Retail Commerce framework is built using two SharePoint collection sites - one for authoring the content and the other as the external facing published site. This approach is an uptake of Microsoft SharePoint's cross-site publication functionality. Let's first of all look at the authoring site. The authoring site is built to contain the raw product information and attributes as well as the product catalog that we've been looking at. The product master and hierarchy data in this site is contained in lists and the term set and is populated from the CRT DB primarily the 'Retail Publishing Job'. This is a critical job in this process. You can view the status of this job, job history and definition in SharePoint Central Administration - Monitoring. You can see it being scheduled and executed in the below screen: (note: you'll need to be logged in with domain\administrator privileges to run some of the features in here)

So upon executing this job, what happens is that data is taken from the CRT DB and it's pulled into the product catalog (or authoring) site as lists and the term store. It also does a final status update back to Dynamics AX to keep everyone in the loop as to what's going on.

Now its SharePoint's turn to take over. ..

Step 3: Publish to the SharePoint Publishing Site

Cross-site publishing is a feature of SharePoint. The lists that we've populated in the authoring site are crawled (indexed) by SharePoint Search and as a result the data will exist in the SharePoint search DB. When the online store's web site renders the products it is done by querying the SharePoint search (which is internally accessing the SharePoint search DB).

So there you have it. As mentioned above, our truly integrated, omni-channel retail solution enables retailers to control their website data and hierarchy data directly from Dynamics by securely managing data in a controlled, secure framework as described above.

And before I sign off, big thanks to Sergey Pikhulya, who is the Yoda of this young Skywalkers' road to commerce enlightenment…

Peter is a Retail Solution Architect for the Centre of Excellence EMEA team

Simple “Publish-Subscribe” integration with Dynamics CRM using Azure Service Bus Topics/Subscriptions

2013-03-05T16:55:00Z

Implementation of “publish-subscribe” based integration where Dynamics CRM acts as publisher is very common. In this article, I will talk about how “Azure Service Bus Topics/Subscriptions” can be used with Dynamics CRM to create a “publish-subscribe” based integration. I will not talk about “Azure Service Bus Topics/Subscriptions” in detail but focus more on usage scenario and integration.

What is “Publish-Subscribe” Integration?

First step is to know what is “publish-subscribe” (commonly known as pub-sub) based integration. It is an integration pattern.

In simple language, in pub-sub integration, the subscribers are interested in certain messages and they keep looking for the messages at certain place called “bus”. When the publisher publishes or creates the message in the “bus”, each subscriber interested in this message gets a copy of it. There could be multiple subscribers for the same message.

Subscribers could be interested either in a type of message or a message with certain content. When they are interested in message with certain content, content based routing is used to make that message available to the subscriber.

I recommend you read the following links to learn more about publish-subscribe and content based routing –

Publish Subscribe - http://www.eaipatterns.com/PublishSubscribeChannel.html

Content Based Routing - http://www.eaipatterns.com/ContentBasedRouter.html

Business Scenario for “Publish-Subscribe”

Let me share couple of real scenario examples.

There is a utility company which provides water and waste management service to citizens. It has a CRM system, billing system, messaging system and mapping (GIS) system. When a customer (message) is created in the CRM system (publisher), the billing, messages, GIS systems (Subscribers) need a copy of customer data to perform follow-up tasks and automation. For instance – billing system will create a billing account for the customer, the messaging system will send welcome message with customer account details on preferred communication channel and GIS system will update customer address in the database for mapping purpose. This is an example where subscribers are interested a message type.

Another example is for content based subscription. There is a Telco company which provided services to a massive geography. It has logically divided the geography into four regions. It has a centralized CRM system but the billing system has been partitioned into four physical instances – one for each region. When the customer (message) is created or updated in the CRM system (published), it has to be updated into respective billing system (subscriber) based on the region (content) of the customer.

The following are critical components of the publish-subscribe pattern –

Publisher
Message (Which published and Subscribed)
Content Rule (for content based routing)
Bus
Subscriber
Last but not least “Reliability” in terms of secure message handling, guaranteed delivery, retries, error message handling, exception handling etc.

Azure Service Bus Topics/Subscriptions as “Publish-Subscribe” Engine

The Windows Azure Service Bus Topics/Subscriptions provides a light-weight but reliable and scalable platform for “public-subscribe” based integration. It has the entire ingredient for such implementation –

Topic Definition (“Bus”)
Subscription Definition
SqlFilter (content based rule for subscription or routing)
BrokeredMessage (creating and publishing messages)
Reliability

If I map the first scenario from the above with Service Bus Topics/Subscriptions architecture, it looks like the following –

We need to do the following for integration –

Create service bus namespace on Azure Portal
Create “Topic” under service bus namespace
Create “Subscriptions” under “Topic” based on number of subscribers
Write “Publisher Code” which takes message data (customer in this case) from the publisher, connects with service bus and then publish message to the “Topic”
“Topic” will internally create copies of the message into subscription queues based on subscriptions defined
Write “Subscriber Code” which is responsible for reading message from subscription queue. It connects with service bus, takes messages from subscription queue, and connects with subscriber system to process the message for the target subscription system.

If you want to learn about Azure Topics, please refer the following link - http://msdn.microsoft.com/en-us/library/windowsazure/hh367516.aspx

How to use Topics/Subscriptions with Dynamics CRM?

Finally, let’s see how we make Topics/Subscriptions work with Dynamics CRM in simplest form. Let’s take a scenario where when contact is created or updated in Dynamics CRM – the subscribers (billing, messaging, GIS systems etc.) are interested in it.

First step is to create service bus namespace, Topic and Subscriptions.

Next write “Publisher Code” in plugin and register plugin for “contact” entity for create and update events. The code will connect with service bus and publish “contact” instance to the “Topic”. The code snippet will look like the following –

 string _ConnectionString = "Endpoint=sb://demosb-ns.servicebus.windows.net/;SharedSecretIssuer=owner;SharedSecretValue=u5TOVcfSgWC1lKX8+KiHH/7znVP3p3pX23ddwed342edd="; 
 string topicName = "demotopic"; 
 public void Execute(IServiceProvider serviceProvider) 
 { 
 try 
 { 
 IPluginExecutionContext context = (IPluginExecutionContext)serviceProvider.GetService(typeof(IPluginExecutionContext)); 
 
 Entity entity = (Entity)context.InputParameters["Target"]; 
 
 if (entity.LogicalName.Equals("contact")) 
 { 
 TopicClient Client = TopicClient.CreateFromConnectionString(_ConnectionString, topicName); 
 
 BrokeredMessage message = new BrokeredMessage(entity); 
 Client.Send(message); 
 } 
 } 
 catch (Exception) 
 { 
 throw; 
 } 
 }

Based on subscription definitions under “Topic”, the topic will create copies of the “BrokeredMessage” and assign to subscription queues.

Write “Subscriber Code” which will read “BrokeredMessage” from the subscription queue and do the message processing. This code is responsible for reading message from subscription and passing to subscriber system for processing purpose. The code snippet look like following -

string _ConnectionString = "Endpoint=sb://demosb-ns.servicebus.windows.net/;SharedSecretIssuer=owner;SharedSecretValue=u5TOVcfSgWC1lKX8+KiHH/7znVP3p3pX23ddwed342edd="; string topicName = "demotopic"; string subName = "demosubscriptio"; SubscriptionClient Client = SubscriptionClient.CreateFromConnectionString (_ConnectionString, topicName, subName); Client.Receive(); // Continuously process messages received from the subscription while (true) { BrokeredMessage message = Client.Receive(); if (message != null) { try { Entity entity = message.GetBody<Entity>(); //TODO: WRITE CODE TO CONSUME THIS ENTITY INSTANCE message.Complete(); } catch (Exception) { message.Abandon(); } } }

The big question is where to host the “Subscriber Code”. You can see that this code snippet runs in loop and looks for any message published. We need a host which can home this code snippet. There are couple of choices for host
- SSIS Package executed using SQL Job
- Windows Service
- Console Application scheduled using Windows Scheduler

Conclusion

You can see it is a simple, elegant but very reliable and powerful way of implementing publish-subscribe pattern with Dynamics CRM. The implementation can have many faces and variant – I leave that to your design and scenario.

Hope you find this article useful.

Introducing the SharePoint Product Catalog site for Dynamics AX Retail

2013-02-12T22:51:00Z

In my previous blog, I looked at how changes made in Dynamics AX are then directly reflected in your external facing website (http://blogs.msdn.com/b/dynamics-coe/archive/2013/02/04/updating-your-commerce-catalog-directly-from-dynamics-ax.aspx). In order to start to understand how this works, we need to understand some of the components of the Dynamics AX Commerce platform. Dynamics AX Commerce utilises two SharePoint site collections, connected through SharePoint 2013's Cross-Site Collection Publishing feature (http://technet.microsoft.com/en-us/library/jj656774.aspx). One is for publishing content and the other is for authoring content. The authoring content component is called the Retail Product Catalog site and it holds products, product catalogs and associated information that are then used in your external website. In this post, I will walk you through some of the features of the Product Catalog and how useful and simple it is to manage your website data.

Let's get started with the home page. The home page of the Product Catalog site looks like this:

There is a host of things we can do in this site from viewing your online product data to managing hierarchy information. Let's have a look at these.

1. Viewing products

To view the products, click on the Lists menu item on the left and there is a list containing all the products and the associated metadata held against each product for use on the website. You can then drill into each product and view or manage product data.

2. Viewing the Catalog

The Product Hierarchy utilises the standard SharePoint Term Set functionality and can be viewed in the Product Catalog "Term Store" (for more information on Term Sets refer to tech net at http://technet.microsoft.com/en-us/library/ee519604.aspx).

Access the Term Store from the Product Catalog home page, click on "Manage item hierarchy in Term Store". Expand the Site Collection and the product navigational hierarchy is displayed (you'll notice it matches exactly to the navigational hierarchy we created in Dynamics AX - see my previous blog on updating commerce catalogs).

So what is the real point of this? Well, first of all, you’ve now got a window into all the product data that has come from Dynamics AX and is now sitting in SharePoint. Then, after being pushed into defined SharePoint lists, that data is being used by the powerful SharePoint 2013 search, crawling (indexing) functions used in your external facing website. In addition, through this site you can run other cool functions such as managing your custom sort options, managing your faceted navigation, defining workflow and general site settings. In fact, the more you start to play with the Product Catalog site, you'll see even more powerful functions to maintain your website data.

In my next blog, we'll explore one of those additional functions of the Term Store: How to manage your faceted navigation through the Product Catalog site.

Peter is a Retail Solution Architect for the Centre of Excellence EMEA team

Storage requirements for Microsoft Dynamics AX

2013-02-10T10:22:00Z

Overview

There are many misunderstandings about storage requirements for Microsoft Dynamics AX. Microsoft Dynamics AX is an ERP system with mixed workload that mostly looks like typical OLTP with wide range of query types.

Any mistakes in storage implementation increase risks to performance and cost a lot. Microsoft Dynamics AX has an intense use of storage , besides the queries it utilizes Read Committed Snapshot Isolation feature, and may have temporary tables stored in SQL Server TempDB. In addition, the queries can contain complex joins due to the table inheritance that exists in Microsoft Dynamics AX starting from 2012 version.

It is a common business practice that Microsoft provides storage hardware requirements to the hardware vendor, and then the vendor produces the detailed hardware specifications. Microsoft is not responsible for the third party hardware setup and configuration.

Usually Microsoft and hardware vendor engineers tune the disk storage working together on an implementation phase. The tuning is one of the points of the possible storage re-configuration.

Microsoft approach in I/O calculation and Best Practices are described in the article available at http://technet.microsoft.com/ru-ru/library/cc966412(en-us).aspx (see requirements for OLTP data and log described in ‘I/O related performance counters and their meanings’ table).

General description

Having no specific storage model to be considered, the storage sizing and suggestions are based on the requirement to utilize RAID 10 or similar RAID type that is recommended in a write-heavy environment. It is recommended to use separate disk array for testing environment and other workloads such as reporting or analysis to minimize an influence on production environment.

SQL Server database files should be located on physical disks fully dedicated for SQL Server. For better performance, it is recommended to avoid sharing with other applications, Locally attached storage (DAS) may be faster, SANs are usually easier to manage.

Dynamics AX database data file(s), Dynamics AX database log file and TempDB should be on own volumes.

For the AX database data file(s) you can create multiple data files within a single file group. Table partitioning is supported in Microsoft Dynamics AX 2012 but it is not a general recommendation. If you decide to implement table partitioning for large and heavily used tables you also need to be sure that the underlying infrastructure (disk/controller setup) is capable of giving you the additional performance gains.

For the sector (stripping) size you should consider 8 to 64 KB or any other value your SAN vendor recommends. The number should be dividable by 8 as SQL Server works with pages of 8 KB in size.

It is recommended to move analysis and reporting data to dedicated disk set, so that this data has no influence on SQL Server operations and I/O channels.

Microsoft highly recommends using disk alignment. Disk alignment is a required optimization and must be applied by storage vendor during setup. Disk alignment provides a significant increase in system performance. Failure to perform disk alignment can decrease performance by 10 to 15 percent in RAID array systems. See the article on Microsoft site http://support.microsoft.com/default.aspx?scid=kb;en-us;923076&sd=rss&spid=3198 for the details and updated version of the Diskpart tool.

It is recommended to use maximum number of spindles for I/O operations; for example, for 2 Tb set in RAID 10 it is better to use 30 disks x 144 Gb instead of 4 disks x 1 Tb. SATA disks are not recommended.

RAID trade offs

We would like to reference whitepaper "Performance Tuning Guidelines for Windows Server 2008" available at http://www.microsoft.com/whdc/system/sysperf/perf_tun_srv.mspx

Configuration	Performance	Reliability	Availability	Cost, capacity, and power consumed
RAID 0+1 (striped mirrors) Requirements: Two-disk minimum.	Pros: Two data sources for every read request (up to 100% performance improvement). Balanced load. Potential for better response times, throughput, and concurrency. Cons: Writes must update mirrors. Difficult stripe unit size choice.	Pros: Single loss and often multiple losses (in large configurations) that are survivable.	Pros: Single loss and often multiple losses (in large configurations) that do not prevent access.	Cons: Twice the cost of RAID 0 or JBOD. Up to 2X power consumption.
RAID 5 (rotated parity) Requirements: One additional disk required. Three-disk minimum.	Pros: Balanced load. Potential for better read response times, throughput, and concurrency. Cons: Up to 75% write performance reduction because of RMW. Decreased read performance in failure mode. All sectors must be read for reconstruction; major slowdown. Danger of data in invalid state after power loss and recovery.	Pros: Single loss survivable; “in-flight” write requests might still become corrupted. Cons: Multiple losses affect entire array. After a single loss, array is vulnerable until reconstructed.	Pros: Single loss does not prevent access. Cons: Multiple losses that prevent access to entire array. To speed reconstruction, application access might be slowed or stopped.	Pros: Only one more disk to power. Cons: Up to 4X the power for write requests (excluding the idle power).
RAID 6 (two separate erasure codes) Requirements: Two additional disks required. Five-disk minimum.	Pros: Balanced load. Potential for better read response times, throughput, and concurrency. Cons: Up to 83% write performance reduction because of multiple RMW. Decreased read performance in failure mode. All sectors must be read for reconstruction: major slowdown. Danger of data in invalid state after power loss and recovery.	Pros: Single loss survivable; “in-flight” write requests might still be corrupted. Cons: >2 losses affect entire array. After 2 losses, an array is vulnerable until reconstructed.	Pros: Single loss that does not prevent access. Cons: >2 losses prevent access to entire array. To speed reconstruction, application access might be slowed or stopped.	Pros: Only two more disks to power. Cons: Up to 6X the power for write requests (excluding the idle power).

Configuration

Performance

Reliability

Availability

Cost, capacity, and power consumed

RAID 0+1 (striped mirrors)

Requirements:

Two-disk minimum.

Pros:

Two data sources for every read request (up to 100% performance improvement).
Balanced load.
Potential for better response times, throughput, and concurrency.

Cons:

Writes must update mirrors.
Difficult stripe unit size choice.

Pros:

Single loss and often multiple losses (in large configurations) that are survivable.

Pros:

Single loss and often multiple losses (in large configurations) that do not prevent access.

Cons:

Twice the cost of RAID 0 or JBOD.
Up to 2X power consumption.

RAID 5 (rotated parity)

Requirements:

One additional disk required.
Three-disk minimum.

Pros:

Balanced load.
Potential for better read response times, throughput, and concurrency.

Cons:

Up to 75% write performance reduction because of RMW.
Decreased read performance in failure mode.
All sectors must be read for reconstruction; major slowdown.
Danger of data in invalid state after power loss and recovery.

Pros:

Single loss survivable; “in-flight” write requests might still become corrupted.

Cons:

Multiple losses affect entire array.
After a single loss, array is vulnerable until reconstructed.

Pros:

Single loss does not prevent access.

Cons:

Multiple losses that prevent access to entire array.
To speed reconstruction, application access might be slowed or stopped.

Pros:

Only one more disk to power.

Cons:

Up to 4X the power for write requests (excluding the idle power).

RAID 6 (two separate erasure codes)

Requirements:

Two additional disks required.
Five-disk minimum.

Pros:

Balanced load.
Potential for better read response times, throughput, and concurrency.

Cons:

Up to 83% write performance reduction because of multiple RMW.
Decreased read performance in failure mode.
All sectors must be read for reconstruction: major slowdown.
Danger of data in invalid state after power loss and recovery.

Pros:

Single loss survivable; “in-flight” write requests might still be corrupted.

Cons:

>2 losses affect entire array.
After 2 losses, an array is vulnerable until reconstructed.

Pros:

Single loss that does not prevent access.

Cons:

>2 losses prevent access to entire array.
To speed reconstruction, application access might be slowed or stopped.

Pros:

Only two more disks to power.

Cons:

Up to 6X the power for write requests (excluding the idle power).

The following are sample uses for various RAID levels:

RAID 0+1: A general-purpose combination of performance and reliability for critical data, workloads with hot spots, and high-concurrency workloads.
RAID 5: Web pages, semi critical data, workloads without small writes, scenarios in which capital and operating costs are an overriding factor, and read-dominated workloads.
RAID 6: Data mining, critical data (assuming quick replacement or hot spares), workloads without small writes, scenarios in which cost or power is a major factor, and read-dominated workloads.

Storage configuration

The number of spindles required is highly dependent on the hardware configuration and vendor chosen. Since there is no industry standard for the storage subsystem and different vendors choose different disk system architectures, we highly recommend you consult with your hardware vendor to provide suggestions around the disk subsystem such as the number of spindles.

For optimal database performance, we suggest you utilize smaller number of spindles per group. In this way, we can achieve higher levels of disk access and thus better read/write times. With a specific vendor’s RAID implementation, however, this suggestion may not be always valid.

The following graph illustrates an example where amount of IOs is not well supported by spindles. TempDB is the most prominent example. Its high activity (both database files and log) is supported by only 8 spindles.

With today’s vendor specific RAID implementations, various other factors come into play such as the amount of disk drive cache, the cache controller, the particular vendor specific RAID implementation and others. You need to ensure your hardware vendor is involved in the storage design to provide you with a configuration that is specific to the hardware chosen and that provides you with the best cost/performance ratio.

Additional disk space is required for SSRS/SSAS. If you cannot calculate the disk space required for SSAS/SSRS at the project starting, consider adding about 10-20% of the production database size for the cubes and temporary data.

Examples

Now you may say that the theory is not enough to get a clear vision of the requirements.

We can refer you to the official benchmark reports where storage configurations are listed, and you may correspond it to the tested functionality and workload. The benchmark whitepapers are available at TechNet http://technet.microsoft.com/en-us/library/hh536205.aspx, the detailed results can be downloaded from CustomerSource or PartnerSource.

Another example illustrates a storage configuration dependency on performance rather than actual data size, one disk selected by data size cannot support a workload. We may have mid-size company with no specific operations and verticals such as Manufacturing or Retail and without internal CRM module implemented. To calculate the database size we use an assumption that 1 million transactions (in Unicode) in General Ledger may take about 5 GB of storage space in a case of typical environment (including corresponding transactions related to Bank, Account Receivable and Payable, etc.). Next, data growth in accordance to the company strategy should be applied, say 30%. SQL Server 2008 Data Compression feature will be also taken into consideration. Then a suggestion may have approximately 500-600 GB external storage for database server based on RAID 10, 20-24 Disks For data at 180 IOPS per disk, 4 disks for log, 8-10 disks for TempDB. Note that every environment is unique and the example values should not be applied to a real implementation without analysis of the planning functional and technical specifics.

Summary

It is recommended:

To have any storage LUN that should have response time not higher than 10-20 Msec.
To do a storage check according to "Predeployment I/O Best Practices" whitepaper http://technet.microsoft.com/en-us/library/cc966412.aspx
To use RAID 10 if possible for all LUNs or at least for LUNs that host log files, Tempdb, and main database. For example, HP whitepaper "HP StorageWorks 4000/6000/8000 Enterprise Virtual Array configuration best practices white paper" and other documents from Microsoft and storage vendors provide the following guidance: "RAID5 sets need twice as many writes to store data (four writes vs. two for RAID10)" and "RAID10 typically performs better than RAID5 under OLTP or intense write I/O activity scenarios".
To support LUNs with as many physical spindles as possible. If it is not possible to configure all disks under RAID 10, create two sets of disks: RAID 5 for data and backup and RAID 10 for logs and TempDB. If several database files are created and LUNs are not spread across all available disk drives, create as many files as the number of LUNs and distribute files evenly across all LUNs.
Pay as much attention to TempDB performance as to performance of main database.

Alexei is a Technical Architect for the Centre of Excellence EMEA team

Updating your Commerce Catalog directly from Dynamics AX

2013-02-04T20:38:00Z

Microsoft Dynamics AX2012 R2 included the release of an integrated Commerce platform built on and using Microsoft technologies. If you haven't seen the details and in particular the impact on retailers I suggest you read Michael Griffiths blog here (http://blogs.msdn.com/b/dax/archive/2012/11/16/the-new-retail-reality-are-you-ready.aspx)!

Fundamental to the Dynamics AX solution is a centralised, true omni-channel retail product and catalog management function that drives all your channels including stores and your web. No costly and high risk interface required to be built here. It’s a single solution working out of the box with low total cost of ownership.

In the first of a series of blogs on using the powerful features of this release, here's the quick and easy guide to updating your commerce catalog directly from Dynamics AX.

Step 1: Make changes to your catalog as required

In this example we're going to extend the structure of our web navigational hierarchy. Contoso, our electronics superstore, is no longer going to sell home appliances. As a result, we need to remove "Home appliances" from the website category hierarchy.

So here's what our website hierarchy looks like before we start:

If we look in Dynamics AX, we see that the above hierarchy is represented in the retail navigation hierarchy attached to our web channel. In the below screenshot, the hierarchy on the left shows the screen where this hierarchy is maintained in Dynamics AX. As part of our scenario, I need to inactivate the "Home appliances" node. To do this I click Inactivate at the top of the screen and the result is shown below on the right (If you want more detail on changing retail navigation and product hierarchies, stay tuned for a future blog where I'll explore these features).

Step 2: Publish your online channel

Once you're happy with the new navigational hierarchy, you need to go to your online channel form in the Retail module. You'll note an existing publishing status of 'Published'. Simply press 'Edit' and then 'Publish' on the ribbon bar and you're ready to roll.

Once you do this, you'll note the publishing status turns to "In progress".

Now if you're impatient like me, you can run a couple of processes to speed up the background work. We can call these steps 2a) and 2b) if you like.

2a) Run the Create Actions job to analyse any changes made in synchronised data elements, then

2b) Run the Commerce Data Exchange process. If you're looking at an out of the box installation, this process is called "A-1075_OC"

Note the publishing status of our online channel again…!

Step 3: Refresh your web page

So that's done, go back to your web page and click refresh. Voila!!

There you go, three easy steps!

No web re-programming required, no code changes and therefore no need to call the developers down from upstairs - changes made in Dynamics AX are directly reflected in the web.

In upcoming blogs, I'll take a deeper dive into each of these components to show how you can drive further productivity improvements in your commerce data management activities.

Peter is a Retail Solution Architect for the Centre of Excellence EMEA team

Using Windows Azure Blob Storage with Dynamics CRM

2013-01-30T10:19:00Z

In this article we are going to talk how Windows Azure Blob Storage can be used with Microsoft Dynamics CRM.

Business Scenario

In many of the CRM implementations, we come across requirement where certain documents are required to be linked with records such as accounts, contacts, cases, activities etc. For example –

Insurance and Telco companies want to attached scanned copies of contracts, applications, health inspection reports, address/identity proof documents of the customers
Public sector – store job orders, inspection reports, citizen document copies etc.

In cases where these documents are large in number and size, we try to avoid out of box “Attachment” feature of the Dynamics CRM because it rapidly increases the CRM database size. We prefer using some document management solution such as SharePoint, Documentum and integrate with Dynamics CRM. In many cases, the document management solution comes as overhead because –

The need is to just link documents with records – nothing more
No workflow or search required
Upfront large investment in DMS software as well as storage space
Operational overhead in terms of backup and maintenance

Solution

The Windows Azure Blob Storage is an easy and economical option here. The following are merits of using blob storage in place of document management solution in such scenarios -

Blob is storage focused only
Provides storage redundancy – no need for back up, disaster recovery in place.
Secure access provided. The storage data can also be encrypted
No upfront investment – pay as you go (storage size) and it is very low-priced – check this out - http://www.windowsazure.com/en-us/pricing/calculator/

What it takes to mingle both?

It is very easy to make both Dynamics CRM and Azure Blob Storage marry. There are well defined and documented APIs for the same. You can custom code integration as per need. I have built a small application (asp.net web application) which can make this integration very simple. The application has a user interface as following –

With this application, you can do the following –

Create a container (folder) for each record using record identifier in Windows Azure Storage. Upload record specific documents in this folder.
You can upload, download, list and delete documents
Can upload any type of document and media
Enable role based access to upload, download, list and delete functions
Works with both Dynamics CRM on-premise and online

Installation and Configuration of Sample Application

I have attached code of the application in the article. Let me take you through steps to perform installation and configuration of the application.

1. Create Windows Azure Storage Account – First step is to buy Windows Azure subscription and then create windows Azure Storage Account under your subscription. Please refer the following link - http://www.windowsazure.com/en-us/manage/services/storage/how-to-create-a-storage-account/

2. If we try to understand Windows Azure Blob Storage structure in simple terms – A Windows Azure Storage Account can have multiple Containers. Each Container then can store multiple documents and media – each called one Blob. This application creates one container for each record then stores record specific documents and media in this container.

3. I assume you already have Dynamics CRM instance (online or on-premise) ready.

4. Download attached application (asp.net web application) code and make changes to connection strings in web.config file –

<add name="blobstring" connectionString="DefaultEndpointsProtocol=https;AccountName=<STORAGE_NAME>;AccountKey=<ACCOUNT_KEY>"/>

<add name="parentIdentifier" connectionString="<https://CRM_SERVER_NAME>;mainpage.aspx"/>

</connectionStrings>

Replace <ACCOUNT_KEY> with primary key of the storage account (you can find in azure management portal)
Replace <https://CRM_SERVER_NAME> with Dynamics CRM Server name which we want to integrate. Note: This setting makes sure that you cannot invoke this application from any other place than from Dynamics CRM web site.
Please replace <STORAGE_NAME> with storage account name created in step-1.

5. Deploy the application –

When using with Dynamics CRM online, please publish this application to Windows Azure Web Site. Refer this link - http://www.windowsazure.com/en-us/home/scenarios/web-sites/
For Dynamics CRM on-premise, you can publish this application to IIS server or to Windows Azure Web Site.

6. Integrate with Dynamics CRM – These are two ways to integrate –

a. Using IFRAME – The application has been designed to work by default with IFRAME. It can be configured at entity form level. When you configure the application for an entity, you can then link a document or media to entity record using azure blob as storage. Please perform the following steps for the configuration –

i. Open entity form for customization. It can be any entity such as account, contact, case, order etc.

ii. Insert IFRAME on the entity form.

iii. Set URL of the entity as https://<web_server_name>/mainpage.aspx . The <web_server_name> is the IIS server name or azure web site name where application has been hosted.

iv. Please be sure that you have checked “Pass record object-type and unique identifier as parameters” check box. It is very important to check this because with this setting the record GUID is passed in query string and application uses that to create unique container for the record in the azure storage. Without this setting, the application will not work.

v. Please also ensure to un-check “Restrict cross-frame scripting, where supported” check box. It is another important setting because otherwise application form will not post back and it will throw out into popup when posting back.

vi. Finally save and publish the form customizations.

vii. You can now open entity record and link files to the record. Note: In case of new record, the application will not upload files unless the record has been saved. Remember it needs record GUID to create container for the record in the azure blob.

b. Using Ribbon Button – you can also configure the application with ribbon button but it needs some level of coding. I plan to create a ribbon in next version which will make integration easier. For now – please do the following –

i. Open entity form for customization.

ii. Create a ribbon button. Customize ribbon button to call a JavaScript function. The Java function should open the URL (https://<web_server_name>/mainpage.aspx?id=<GUID>) using Window. Open method. The <web_server_name> is the IIS server name or azure web site name where application has been hosted. The <GUID> is the GUID of the entity record.

iii. In the application, please open “mainpage.aspx.cs” file and remove the method “CheckReferalPage” and any reference to this method. Please compile and re-host the application.

7. Configure Role Based Access Control – I have not provided any role based access in the application but there are extensions available to easily configure the same. Please do the following –

a. When using with IFRAME –

i. Open entity form for customization.

ii. Create a JavaScript code on the “Form Load” event which passes user roles (Xrm.Page.context.getUserRoles()) in the hidden text box (id=iroles, name=txtroles) of the IFRAME page.

iii. In the application, please open “mainpage.aspx.cs” file and write role based access behaviour in private method “SetRoleBasedAccess”. Essential, you will read user role names passed and enable\disable control as per access provided to the role.

b. When using with Ribbon button - In ribbon button, implement the logic of JavaScript written above using HTTP POST methods.

Conclusion

This is a sample implementation to expedite basic integration of Windows Azure Blob with Dynamics CRM. I am sharing code with you; please feel free to make necessary changes in the code as required. Hope you like this article.

Building Dynamics CRM Applications for Windows 8 – Practical Approaches

2013-01-21T20:57:00Z

Introduction

We are living in the age of “apps”. A quick search on internet will show that there are close to 15,000 apps registered in Windows 8 marketplace while Android is sprinting ahead with approximately 600,000 aps and Apple will reach record 1 million anytime now. We have huge opportunity in this space.

The Microsoft Dynamics CRM is also evangelizing apps for Windows 8. As per official communication, the Windows 8 app for Dynamics CRM 2011 will be available by mid of 2013. In addition, you can also build your custom app which sources data from Dynamics CRM. I am sure you will come across business scenario (different looks and feel app, app leveraging old versions 3.0/4.0 CRM etc.) where you need to build custom Windows 8 apps for Dynamics CRM.

This article is focused to discuss approaches to integrate Dynamics CRM in Windows 8 apps and pros-cons associated with them.

Challenges

If you try to use CRM SDK with Windows 8 app, you encounter loads of build errors because CRM SDK and Windows 8 app use two different platforms which are not compatible with each other. The CRM SDK classes are built with .Net Framework 4.0 as target while Windows 8 apps use “.NET for Windows Store Apps”. You find the same type of errors whether using early binding or late binding methods.

Solutions

So, how do we build Windows 8 apps which can talk to Dynamics CRM? There are roughly three approaches which we can take – each with their set of pros and cons.

Use WinRt compatible CRM Libraries

The Microsoft Dynamics Team has developed WinRt compatible CRM libraries (WinRt.Microsoft.Crm.Sdk.Proxy and WinRt.Microsoft.Xrm.Sdk) which you can use in Windows 8 app. Right now, the libraries are in pre-released state so you can download the code of the libraries along with a sample using them. I presume that the WinRt SDK will be officially released with the release Windows 8 client for Dynamics CRM. You can download WinRt compatible Libraries and sample from the following link –

http://download.microsoft.com/download/1/A/A/1AA59217-D571-4E65-B037-FE59DD945A13/CRMSLSample.zip

Pros

Cons

The SDK is the way to go as it will be integral
part of CRM release when it happens.

Works with CRM Online (Live and Office 365) ,
Claim Based and IFD deployment

Does not work with CRM on-premises deployments using
Active Directory authentication. [at present]

It is currently in sample stage only.

Will not work with old versions of Dynamics CRM (4.0
and 3.0).

Use Bridge WCF service

This is a simple approach which works with the current release of CRM SDK. It uses a WCF service as an intermediate service to normalize platform compatibility between CRM SDK and Windows 8 app. The following are the high level steps to use intermediate service –

Create a WCF Services project. Set target framework as .NET 4.0. It is important because the WCF service will use CRM SDK which is .NET 4.0 based.

As per business need, create operations (methods) in WCF Service. Use data contracts and parameters which are compatible with “.NET for Windows Store Apps”. In my personal experience, I used native types (STRING, INT etc.), collections and also data classes without any hassles. Please use the following link to see what data types are compatible - http://msdn.microsoft.com/en-GB/library/windows/apps/br230232.aspx

In WCF operations or methods, use CRM SDK APIs to implement the method. You can use both early and late binding way of coding as per your comfort.

Finally, reference this WCF service in Windows 8 app and make calls to operations. If you are new to this, please refer the following links -

http://msdn.microsoft.com/en-us/library/hh556233.aspx

http://www.tapanila.net/consuming-wcf-service-with-windows-8/

Pros

Cons

Simple to use. Works with current release of CRM
SDK.

Works with CRM Online (Live and Office 365), IFD
deployment and On-Premise using Windows Authentication

Possible to make calls to old versions (3.0 and
4.0) of Dynamics CRM.

More development effort due to development of
intermediate WCF method.

You have to plan for deployment of intermediate WCF
service on some box. Overhead deployment task.

After the release of CRM SDK for Windows 8 App, this
approach should not be used unless talking to old versions (3.0, 4.0) of
Dynamics CRM.

Tweak Proxy Class in Early Binding

This approach also uses current release of CRM SDK but works only with early binding method. In brief, you create proxy for CRM web service and then change proxy class code to make it compatible with Windows 8 apps. Here are the steps –

Use CrmSvUtil utility to create proxy class for CRM Web Service

Include proxy class in your Windows 8 app project. When you build the project it will throw close to 500 errors in proxy class due to platform in-compatibility between Windows 8 app and proxy class framework APIs.

In proxy class, most of the errors are related to “System.ComponentModel” class which does not support members like INotifyPropertyChanging, PropertyChangingEventHandler etc. in “.NET for Windows Store Apps”.

You need to perform marathon task of manually removing and commenting/disabling these member usage and related code in proxy class.

Note: Deleting these reference will have no negative impact on the functionality.

Once all the references are deleted, compile the code. After successful compilation, you are good to use this proxy class like you do in normal .NET client.

It is advisable to include proxy class in Portable Class Library (PCL - targeting .NET Framework 4.0 and above) project in place of Windows 8 client project directly. The PCL project then can be referenced in Windows 8 client project. Please refer the following link to learn more about PCL - http://msdn.microsoft.com/en-us/library/gg597391.aspx

There is a way to generate smaller proxy class by generating only those entities which are required. It simplifies things because then clean-up is performed on a smaller code. Please check the following link for the same - http://erikpool.blogspot.co.uk/2011/03/filtering-generated-entities-with.html

Pros

Cons

Simple to use. Use early binding and strong data types.

Can leverage Event-based Asynchronous Pattern (EAP) – async /await in Windows 8.

Works with CRM Online (Live and Office 365), IFD
deployment and On-Premise using Windows Authentication

Lengthy clean-up task. If proxy is regenerated due to
change in entity metadata then clean-up has to be performed each time.

Would recommend as intermediate approach till the CRM
SDK for WinRt gets released.

Will not work with old versions of Dynamics CRM.

Summary

You have choices to use the approach you want. I would recommend using CRM SDK for WinRt when it is released. Till that happens, you can choose between approach 2 and 3. The approach 2 (Bridge Service) has advantage to work with old CRM versions as well. Hope you find this article useful.

Brajendra,

Using windows AD groups for user management in Dynamics AX 2012

2013-01-13T13:33:00Z

Ax 2012 has an interesting feature for user management. Instead of importing the users one by one and administering in the AX environment you can simply create a user for the Active Directory group in the AX. The system will automatically create an AX user for every member of the group when (s)he tries to access the system. This is a dynamic process, the user rights will be adjusted according to the current group membership at each logon. If a user is added to or removed from an AD group the changes will be applied the next logon.

If the user who is logged on once is removed from every AD group that has access to the system, we will get a little unintuitive result. The system will not delete the user from the database (good so far), but the user will not be in any role in the system, not even in the default System User role. So (s)he will be able to log on, but nothing will work:

This is the User screen of an auto imported user (watch the user ID)

And this is, what the user sees from the system once removed from every user group:

This process has quite a few advantages.

The main being, that this process takes the burden of user management form the administrators of the AX system. Instead of having to manage hundreds of users they will have to manage a relatively few groups, and management usually means only creating the group and assign the role membership to the groups.
It will also increase the security of the system, as every functions that related to the authentication (who you are) are managed in their natural place the AD. Ax has only take care of the authorization (OK, given who you are, what are you allowed to do) related to the AX system.
In enterprises it is quite common to have a central user rights management system, usually connected to the HR system. The majority of these systems handle AD groups, but I have not heard one that has an agent handling AX.

The only disadvantage of this is, that the users automatically created by the system will have an id starting with $, see above. The other fields like user name and alias are created correctly.

Because AX seems to be tracking the version of the AD object and modify the user effective roles only if it detects a change there is an interesting side effect you should be aware of (tested it on 2012 CU3). Suppose you have an existing user in the AX and the AD (i.e. the user already logged on to AX). You create a group in the AD and add the user to the group. If you create a user from the AD group in the AX and assigns the roles to it, the user will not get the permissions from the role. What you should do instead is:

Create the AD group empty
Add the group to the AX
Put the member to the group after the AX user is already created.

It will work fine.

Designing the structure of the groups and roles is very project dependent. What was working for us is:

Create a group that will contain all the users of the AX system. Create the AX user for the group, only the default System User role should be assigned to it.
Create an AD group and the corresponding AX user per role.
And let the AD admins administer your group membership.

Illés