SSRS Date Format Issue

Formatting a date can be a common requirement in SSRS reports. Though, we have few built-in methods to play around, it is best if you can do it using format options within the textbox properties. I am just going to demystify something in it.

How to get there;
Right click the text box > Select text box properties > select Number tab > select Date

Now you see this;

Now you can select any format you need.. and that’s the short and sweet way.

Anyway, as I highlighted, I noticed two separate formats which look likes same.
(Do you see what I see?). Now what does this means?

First one shows date as “1/12/2012”
While
Second one shows date as “01/12/2012”

Two different formats, though little unclear.

Plug-in concerns: synchronous or asynchronous, transactional or not …

When developing plug-in we have to make few main decisions based on the requirement. Most fundamental thought comes to our mind is whether we need to do in Pre stage or Post stage, which is usually not hard.

Synchronous or Asynchronous

Then we need to decide, whether it is a synchronous or asynchronous. In my opinion, unless there is very specific reason, it’s good to work synchronous, which is real time. Meaning is once synchronous process is started, user can’t proceed to next step till it finishes. Best fruit is you know if there is any error sooner than later. You will simply see an exception thrown if something is wrong.

Yet, there are specific scenarios you will be forced to go for an asynchronous ones. Best example I encountered is some batch processes that needs a long time to complete. Asynchronous process works in the background, allowing user to proceed to next step. I have done very successful batch processes in asynchronous mode that took 5 to 10 hours to complete.

Problem with asynchronous execution is, you don’t know if an error occur because it’s happening in the background. You may need to check system jobs to see if there are errors.

Transactional or Not

When we discuss about the synchronous and asynchronous modes, we are also forced to discuss about transactions. All asynchronous plug-ins are none-transactional, which means.. if plug-in fails in some point, all the operations happened till that failure are valid. Suppose my batch process needs to process 100 records in one go. If it fails in 61st record due to an data issue, first 60 records have already processed correctly.. Only remaining 40 are un-processed. That’s because asynchronous plug-ins are none-transactional.

In fact, my golden rule for asynchronous ones is use a proper tracing mechanism inside the plugin code. So you are able to see what went wrong after the execution, in case of a failure. Otherwise, how do you know what processed and what not? Knowing Point of failure is important here.

It is best to work synchronous plug-ins for important calculations of payment & etc. for example. Since its best to have nothing as the outcome than having half of the steps… (Ex: Paying the commission for a sale and not doing the sale actually could be horrible than happening nothing.) Fruit of synchronous plug-ins is (with one exception…a special case) they are transactional. That means, if it fails in some point all the previous operations would be reversed. Outcome is 100% or nothing. No need to worry about the point of failure.

Importance of Pre-validation

Let’s talk about the “special case”.. if you register the synchronous plug-in in the pre-validation, it is none transactional. Please refer this article, which explains it really well. It sounds like, the transaction starts in some point and Pre-validation stage occurs before that.

Please note if you write a Pre-Validation Plugin for Create message you will not have the Id since record is not yet created, you need to deal with other fields those available in create.

http://mscrmtools.blogspot.com.au/2011/01/crm-2011-plugins-welcome-to.html

How to throw exception while keeping the changes

Depending on the situation, transactional operations could be annoying too. Recently I wanted to write a plug-in that needs to throw an error to show a message to user, but I didn’t want to roll back what I did so far. Since I need to throw the exception, I have to go for a synchronous plug-in definitely, but it rollbacks everything as soon as they through the exception. Only solution was to register it in pre-validation. (Synchronous in pre-validation is not transactional.. this is the special case we discussed)

So these are some concerns about the plug-in designing.

Update the same entity on Deactivation

This is the code snippet to de activate an entity and it’s straightforward;

SetStateRequest setStateRequest = new SetStateRequest()
{
    EntityMoniker = new EntityReference
    {
        Id = _accountid,
        LogicalName = "account"
    },
    State = new OptionSetValue(1),
    Status = new OptionSetValue(2)
};
crmService.Execute(setStateRequest);

Now, we will see the tricky part. Sometimes we are asked to update some fields in an entity when deactivated. For example, you are required to modify the field values before deactivating an account. Problem is, once you deactivate it, you are not allowed to modify the values. Hence, you need to do it before deactivation. For this we need to register a plug-in for pre- stage of account for state change. (register two steps; setState and setState Dynamic Entity). Below is the code;

public class AccountDeactivation : IPlugin
{
public void Execute(IServiceProvider serviceProvider)
{
    IPluginExecutionContext context = (IPluginExecutionContext)serviceProvider.GetService(typeof(IPluginExecutionContext));

    try
    {
        IOrganizationServiceFactory factory = (IOrganizationServiceFactory)serviceProvider.GetService(typeof(IOrganizationServiceFactory));
        IOrganizationService crmService = factory.CreateOrganizationService(context.UserId);
        Entities.OrgOrionDatamodel orgSvcContext = new Entities.OrgOrionDatamodel(crmService);

        if ((context.InputParameters.Contains("EntityMoniker")) && (context.InputParameters["EntityMoniker"] is EntityReference))
        {
            var targetEntity = (EntityReference)context.InputParameters["EntityMoniker"];
            var state = (OptionSetValue)context.InputParameters["State"];
            var status = (OptionSetValue)context.InputParameters["Status"];

            if (targetEntity.LogicalName != "account")
            { return; }

            if ((state.Value == 1) && (status.Value == 2)) //Identify when the Deactivation is occuring
            {
                //Logic here
            }
        }
    }
    catch (Exception ex)
    {
        throw new InvalidPluginExecutionException("[" + ex.Message + "]" + ex.StackTrace, ex);
    }
    finally
    {
        context = null;
    }
}
}

This plug-in fires on (actually before) deactivation of account. Why?
To fire this below conditions should be met;
- State change should occur
- Resulting values of state and status should be 1 and 2 respectively.
(in fact, this satisfies only when deactivation). Since we register the plug-in in pre stage we still can modify the entity itself if needed.

Note:
This code is working fine for account and many other entities including custom entities. Please check if you need to implement this to entities with complex state and status values such as lead and opportunity. Change the values of conditions (state and status) to pick the correct occurrence you are interested in.

Related Posts;
Sample Plug-in: State change