cub-e.net

just coding...

Important information about supported configurations in the next release for CRM

As we ship the Microsoft Dynamics CRM 2013 Service Pack 1 and CRM Online Spring ‘14 releases, we’re looking ahead to our next release of CRM. As with other releases of CRM in the past, we find the need to add and remove items from our supported configurations list to keep current with technology, and allow us to provide you the best product possible.

Changes in supported platform software

For the next release, we’re removing the following operating systems from our Microsoft Dynamics CRM Server support matrix:

  • Windows Server 2008
  • Windows Server 2008 R2
  • Windows Small Business Server (All versions)

We’re removing the following SQL Server versions from our Microsoft Dynamics CRM Server support matrix:

  • Microsoft SQL Server 2008
  • Microsoft SQL Server 2008 R2

We’re removing Microsoft Dynamics CRM for Outlook support for:

  • Windows Vista
  • Windows Server 2008 Remote Desktop Services
  • Microsoft Office 2007

Our current plan for Microsoft Dynamics CRM Server is to target only Windows Server 2012, Windows Server 2012 R2, and SQL Server 2012 for the next release time frame.

Note that we’re exploring support for SQL Server 2014 with Microsoft Dynamics CRM Server, but we haven’t made a decision at this time.

Changes in items specific to the CRM application

Client API (JS)

We’re removing the following client SDK (JavaScript) APIs:

This means that if your customizations are using any of these API commands, your code will likely break after you upgrade CRM.

We’re modifying the possible return values from Xrm.Page.ui.getFormType to remove the Read Optimized and CRM 4.0 QuickForm Types. This means that we’re removing two values from the possible results of getFormType. However, it’s unlikely that your code will be affected by this because we removed the forms types in CRM 2013.

Please see Client-side Context Reference for CRM 2013 for alternative methods to use

Form system

We’re removing the following form items:

  • Read-optimized forms
  • CRM 2011 forms that were updated in CRM 2013

This means that you must upgrade your forms to use the new CRM 2013 form system before upgrading to the next release.

Entities

The Kit type of Product will be deprecated, which means that we’ll do base testing only and will be removing this feature in a future release. Please update your customizations to not use this entity.

Upgrade rules

We’re making database merge mandatory on upgrade. This means that you won’t be able to bypass this process during the upgrade from CRM 2013 to the next release of CRM.

Email Router

Support for Exchange 2007 connectivity to and from the CRM Email Router will be deprecated, which means that we’ll do base testing only and will be removing this capability from the CRM Email Router in a future release.

Browsers

We’re dropping support for Internet Explorer 8 and Internet Explorer 9.

Note that Internet Explorer 8 and 9 won’t route to Microsoft Dynamics CRM for phones by default, they will continue to route to the main application. However, they won’t provide an optimal experience and any issues reported will need to be validated on a supported browser.

2007 SDK SOAP Endpoint

We’ll be removing this endpoint, which was deprecated in CRM 2013. You shouldn’t use this endpoint for any new extensions.

Kaynak : http://blogs.msdn.com/b/crm/archive/2014/05/14/important-information-about-supported-configurations-in-the-next-major-release-for-crm.aspx

Using Singleton Design Pattern to Call Dynamics CRM Web Service

Using Singleton Design Pattern to Call Dynamics CRM Web Service

About this article, we will develop a code part which is to keep under control that our own created web service connection will be just one time in the memory and always accessible in the application life cycle. We will apply the Singleton Design Pattern to web service call method that is required for this job.

As you know Dynamics CRM 2011 edition (as well as other Dynamics CRM editions) is a web application, if we want to develop our own software is to use its web services. In this case we have to consider the performance of IIS, and we need to develop our practices accordingly. During each transaction in our application to invoke a web service and our own applications as well as IIS unnecessarily causes swelling so that’s why we need to create unique web service connection in the memory and have to access it all the time. That the Singleton Design Pattern can provide it.

Before beginning to develop our own code, I would like to give more information about Design Patterns. In software engineering, a design pattern is a general reusable solution to a commonly occurring problem in software design. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved.

Design patterns were originally grouped into the categories: creational patterns, structural patterns, and behavioural patterns, and described using the concepts of delegation, aggregation, and consultation. 

  • Creational Design Patterns: Creational patterns are ones that create objects for you, rather than having you instantiate objects directly. This gives your program more flexibility in deciding which objects need to be created for a given case.

  • Structural Design Patterns: These concern class and object composition. They use inheritance to compose interfaces and define ways to compose objects to obtain new functionality.

  • Behavioural Design Patterns: Most of these design patterns are specifically concerned with communication between objects.

Now, I can begin to explain “Singleton Design Pattern” which is in "Creational Patterns Group”. The singleton pattern is one of the best-known patterns in software engineering. Essentially, a singleton is a class which only allows a single instance of itself to be created, and usually gives simple access to that instance.

ClassName objectName = new ClassName();   // Standart implementation

in that way we can create a lot of instance of ClassName class, but simply we don’t want it, we need a class which is responsible for creating and maintaining its own unique instance.

It requires a mechanism to access the singleton class member without creating a class object and a mechanism to persist the value of class members among class objects. The singleton pattern is implemented by creating a class with a method that creates a new instance of the class if one does not exist. If an instance already exists, it simply returns a reference to that object. To make sure that the object cannot be instantiated any other way, the constructor is made private so we cannot use standard implementation. Implementation also use a public static property instance as the means of accessing the instance. Note the distinction between a simple static instance of a class and a singleton: although a singleton can be implemented as a static instance, it can also be lazily constructed, requiring no memory or resources until needed. Another notable difference is that static member classes cannot implement an interface, unless that interface is simply a marker. So if the class has to realize a contract expressed by an interface, it really has to be a singleton.

Finally, our structure will be like this:

ClassName objectName = ClassName.MethodName();  // Standart way to call a static method

Standart UML of Singleton Design Pattern:


But I simply convert it to this :

I’m creating the attributes and methods which I need to apply;

 private static Service _serviceInstance;

        private IOrganizationService _organizationService;

        private Guid _controlID;

        private static object _lockObject = new object();

 

        public IOrganizationService OrganizationService

        {

            get { return _organizationService; }

        }

 

        public Guid ControlID

        {

            get { return _controlID; }

        }

 

_serviceInstance property, which is consisting form Service object, actually do all the work. We are looking to it for decide our next action. IOrganizationService is one of instance of Dynamics CRM service object – it is an interface. Our goal is prevent to call repeatedly the formation stage of this object. ControlID were created to looking at how many times we have observed an instance of Service Object with the same id in the system. LockObject completely thought out for the future if you use multithreaded logic, it prevent you from experiencing distress variable. Because the singleton pattern must be carefully constructed in multi-threaded applications. If two threads are to execute the creation method at the same time when a singleton does not yet exist, they both must check for an instance of the singleton and then only one should create the new one.

After the basic needs section, we will start to placement process include the phrase in the right place of code that will do the actual job. I wrote the following block into my Singleton class - that is created with Singleton Design Pattern methodology, I’m going to want to run once for every time.

ClientCredentials clntCredentials = new ClientCredentials();

            clntCredentials.Windows.ClientCredential = new System.Net.NetworkCredential("username", "password", "domain");

            Uri orgUri = new Uri("http://crm url/Organization Name/XRMServices/2011/Organization.svc");

            OrganizationServiceProxy orgService = new OrganizationServiceProxy(orgUri, null, clntCredentials, null);

            _organizationService = (IOrganizationService)orgService;

Next step is to create the code which is check the memory to this service is created before this call. I’m using attributes which are created before to checking and controlling process.

public static Service GetService()

        {

            try

            {

                if (_serviceInstance == null)

                {

                    lock (_lockObject)

                    {

                        if (_serviceInstance == null)

                            _serviceInstance = new Service(Guid.NewGuid());

                    }

                }

 

                return _serviceInstance;

            }

So, In conclusion we have this code block;

class Service

    {

        private static Service _serviceInstance;

        private IOrganizationService _organizationService;

        private Guid _controlID;

        private static object _lockObject = new object();

 

        public IOrganizationService OrganizationService

        {

            get { return _organizationService; }

        }

 

        public Guid ControlID

        {

            get { return _controlID; }

        }

       

        private Service(Guid controlID)

        {

            ClientCredentials clntCredentials = new ClientCredentials();

            clntCredentials.Windows.ClientCredential = new System.Net.NetworkCredential("username", "password", "domain");

            Uri orgUri = new Uri("http://crm url/Organization Name/XRMServices/2011/Organization.svc");

            OrganizationServiceProxy orgService = new OrganizationServiceProxy(orgUri, null, clntCredentials, null);

            _organizationService = (IOrganizationService)orgService;

            _controlID = controlID;

        }

 

        public static Service GetService()

        {

            try

            {

                if (_serviceInstance == null)

                {

                    lock (_lockObject)

                    {

                        if (_serviceInstance == null)

                            _serviceInstance = new Service(Guid.NewGuid());

                    }

                }

 

                return _serviceInstance;

            }

            catch (Exception ex)

            {

                string ErrorDetail = ExceptionHandler.HandleException(ex);

                DetailedLog.CreateLog(System.Reflection.Assembly.GetExecutingAssembly().GetName().Name

                    + " : " + System.Reflection.MethodBase.GetCurrentMethod().ToString()

                    + " : " + ErrorDetail, System.Diagnostics.EventLogEntryType.Error);

 

                return null;

            }

        }

    }

That’s all. We are ready to check. Now, I’m creating a sample console application to check all this process.

     Service service1 = Service.GetService();

            Console.WriteLine(service1.ControlID);

 

            Service service2 = Service.GetService();

            Console.WriteLine(service2.ControlID);

 

            Entity lead = new Entity("lead");

            lead.Attributes["subject"] = "Fuardan Gelenler";

            lead.Attributes["firstname"] = "Barış";

            lead.Attributes["lastname"] = "KANLICA";

            lead.Attributes["companyname"] = "Omerd Business Solutions";

 

            service1.OrganizationService.Create(lead);

 

            Console.WriteLine("Lead created!!");

            Console.ReadLine();

My main goal is to access Service object that is created from instance of CRM Organization Service. In this screenshot, you can clearly see that Service is created in the memory just one time. How is I know? Because ControlID value have same GUID.

Sum of this we can call this GetService() method from everywhere of code but service connection will open only one time.

Baris KANLICA
Dynamics CRM MVP
http://www.mawens.com/aboutme.aspx