CRM 2013 – Development

1) Logging and Handling Microsoft Dynamics CRM 2013 Exceptions – Part 1

2)Lookup for State and Country with Plugins in CRM 2013

3) Fix showModalDialog() method problems in Chrome

Google Chrome version 35 has deprecated the JavaScript method showModalDialog(). Starting with Google Chrome version 37, this method will be turned off by default.showModalDialog() is a method to create a dialog and returns the value set by the dialog. This is a core method used in dialog-return scenarios in Microsoft Dynamics CRM.
Until May 2015, a registry workaround is available to restore the showModalDialog() method. To enable the showModalDialog() method, the following steps can be used: ….
… As you may know, Microsoft CRM 2013 has introduced a new feature called Actions. This great feature allows you to add custom web service messages and process them with a plugin (one possible but not the last use case of this feature) and, at the same time, to call these messages from a JavaScript therefore giving an opportunity to bridge JavaScript and C# code.

6) Integrate SQL Server 2012 Database to CRM 2013 with SSIS

http://ow.ly/DjkvF

7)q.: Can we use rest to create contact or to invoke any other method using rest through console or external application?

Sean McNellis

Sr. Premier Field Engineer at Microsoft

Rahul this will depend on your version of CRM. If it’s CRM online or IFD and CRM 2013+ you can use REST w/ auth using ADAL/AAL (which will interactively prompt the user for authentication – think mobile app scenarios). Recently, a team of our PFE’s and support folks launched a sample mobile solution that is public now – the main author and contributor, Kenichiro, will have an article released on this helper posted to our blog, but in the meantime I’ll provide the links below, the blog will be posted soon on our PFE CRM Blog: http://blogs.msdn.com/b/crminthefield/ – Note this is cross platform and Ken has samples of Windows (phone/tablet), iOS, and Android using this helper plus Xamarin.

Now, using REST for server to server (non interactive scenarios), support for this really isn’t in the product yet – there are ways you can make it work but honestly I would recommend using the /WEB endpoint with SOAP for now until we have more of a solution for this in the product.

If you’re looking for faster message processing (parallel processing or otherwise) or just an easier way to connect and create/dispose of the organizationService I would point you to an auth and Parallel helper that Austin Jones and I have developed and posted on NuGet (http://www.nuget.org/packages?q=PFE+Core) along with source code on CodePlex (http://pfexrmcore.codeplex.com/). If you’re looking for speed and ease of use for a .NET app, I believe this would help you a lot and we’re always working to improve it – this applies to CRM 2011, 2013, and 2015 (we’ll have a 2015 specific NuGet package in the future the 2013 package will work).

Finally, if you use CRM 2011, it’s not supported to use oData for anything outside of the form context – that said if you’re using AD Auth for any version of CRM your app can use default credentials and successfully execute actions against the rest endpoint.

* https://code.msdn.microsoft.com/Mobile-Development-Helper-3213e2e6

* https://code.msdn.microsoft.com/CRM-Service-Utility-for-4ca0c93b
I realize this is a lot of information, but hopefully some of it helps!

8.How to fetch related CRM entity records using Link Entities in single call?.

9. Tutorials for learning about development for Microsoft Dynamics CRM from MSDN

10. CRM SOAP vs REST

Posted on March 9, 2015 at 6:33 pm by Zsolt Zombik /

Similar article: Kendo UI Grid With CRM Data – Rest Version by Jason Lattimer

Definitions

REST

„REST is a software architecture style consisting of guidelines and best practices for creating scalable web services. REST is a coordinated set of constraints applied to the design of components in a distributed hypermedia system that can lead to a more performant and maintainable architecture.

REST has gained widespread acceptance across the Web as a simpler alternative to SOAP and WSDL-based Web services. RESTful systems typically, but not always, communicate over the Hypertext Transfer Protocol with the same HTTP verbs (GET, POST, PUT, DELETE, etc.) used by web browsers to retrieve web pages and send data to remote servers.”
(from Wikipedia)

 SOAP

“SOAP, originally an acronym for Simple Object Access protocol, is a protocol specification for exchanging structured information in the implementation of web services in computer networks. It uses XML Information Set for its message format, and relies on other application layer protocols, most notably Hypertext Transfer Protocol (HTTP) or Simple Mail Transfer Protocol (SMTP), for message negotiation and transmission.”
(from Wikipedia)

“Should I REST or Should I SOAP?”

I have spent hours fretting over the choice between SOAP and REST finding the answer.  Some Web services support one and some support the other. Microsoft Dynamics CRM supports both. Our decision depends on which web service best meets your NEEDS, rather than which PROTOCOL to USE!

SOAP is a heavyweight player: it provides the following advantages when we compare to REST:

Security:

SOAP supports SSL – just like REST – but also support WS-Security (Web Services Security is an extension to SOAP to apply security to Web Services. WS-Security supports identity through intermediaries, not just point to point. It implements data integrity and data privacy.

Transactions:

Need ACID (Atomicity, Consistency, Isolation, Durability) Transactions over a service? You need SOAP. However REST supports transactions, it is not as comprenesive and is not ACID compliant! REST has its own weakness: it is limited by HTTP itself: HTTP is not able to provide two -phase commit across distributed transactional resources, but SOAP can.

Reliability:

SOAP supports WS-ReliableMessaging which is a protocol that allows SOAP messages to be reliably delivered between distributed applications in the presence of software component, system, or network failures.

Let me show you some reasons why REST is almost the “right” answer:

REST uses standard HTTP: it means it is much simpler in some cases:

Creating clients and APIs is easier than SOAP.

Performance:

REST permits many different data formats: SOAP only permits XML. REST supports JSON which is a better fit for data because it parses much FASTER!. REST allows BETTER support for most of browser client.

REST has better performance and it is scalable: REST can be cached, SOAP can’t be.

Conclusion:

Even though REST seems to be in favor now I think there are some cases when SOAP makes sense when you choose it: if I was writing an smart phone application to interface with a service which provides confidental data I would definitely need to use SOAP. All features (WS-Security, WS-AtomicTransaction, WS-ReliableMessaging) are required for this kind of service.

Advertisements

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

%d bloggers like this: