I am planning to start a POC for MS CRM and BizTalk 2010 Integration.
Before that I wanted to know does any body use BizTalk 2010 for integration with MS CRM?
We're using BizTalk 2010 to call into Microsoft Dynamics CRM 2011 Organization service.
There are basically two ways to do this, but I'm committed to find others.
The first way is to use the BizTalk schemas that ship with the SDK along with an external C# based class library helper. This scenario is pretty tell covered on the internet. Note that this scenario will not allow BizTalk to call into the CRM early-bound classes (Account, etc.) It will only allow using the generic CrmEntity object which makes dealing with the mapping a painful experience.
The external helper is necessary to deal with the LiveID federation idiosyncrasies.
This first method has the advantage of being simple. But you cannot use native CRM types from BizTalk.
The second way is to somehow solve the above problems, at least partly. First, it involves building a WCF façade that exposes native early-bound CRM objects (such as Account, etc.) and that deals with LiveID federation.
As generated, the early-bound classes are not serializable so they can't be part of a WCF interface (and service). This can be solved by decorating each and every properties with a DataContractAttribute. Also, read-only properties need to have an extra empty set {} added to them. Please, note that there are a huge number of such (simple) changes to make in the generated classes. Fortunately, as a generated file, the syntax is consistent and a couple of simple RegEx's will do.
On the BizTalk side, you will consume the WCF façade metadata in order to generate BizTalk schemas. Unfortunately, you will end up with huge multi-megabyte files and cross-dependend schemas.
So, first, you have to break the circular dependencies. In my case, I had to add an extra schema to hold shared complex types that were used by both the "contract" and the "metadata" schémas.
Next, you cannot easily use the huge generated schemas in your maps. First opening the map (or the schema alone) will take ages. Second, the compiler will choke and Visual Studio will crash.
To solve this, you need to manually change the GenerateDefaultFixedNodes attribute in your map's .btm XML file.
What I recommend, however, is to use a simplified version of the generated schemas, where you only include nodes and structures that are part of the mapping. Since most nodes are optional, the resulting XML request to the WCF façade will end up being the same.
The advantage of this second method is to be able to deal with native CRM types from BizTalk. But the implementation might sound complicated at first. With proper automation, in practice it works pretty well, even in the face of changes on the CRM side.
None of the methods, however, feel as "native" BizTalk integration. That's why I'm working on finding an alternate way, perhaps by building a dedicated custom binding, but so far without success.
See my question here.
Hope this helps.
Related
I'm working on Dynamics CRM online 2016, the requirement is to create a new entity field inside all the entities that we have in a third party vendor solution (unmanaged).
I'm wondering what is the way to solve this requirement. Because that Solution is huge and it has more than 20 entities.
The third party vendor told me that I have to create a new solution and add all the entities to this new solution and then add the field in each entity. I guess that they want to keep separately new configurations and customizations.
However, my boss told me; you are free to choose working in that solution (third party solution) or to create a new one.
I think it's better and easier to work in the third party solution (because at the end, when I need to migrate these changes to our other instances, I will export and import this solution), however I'm fairly new in Dynamics and in terms of migration process, I do not know what is the best approach.
I really appreciate any suggestion from you guys.
It is fine to work in the third party solution, which I would recommend. If for some reason you prefer, it is also fine to work from a new solution you create.
The key is to understand that solutions do not really matter: The entities themselves exist in the layer of unmanaged customizations of the system. Solutions are simply containers that point to these unmanaged entities.
No matter how many solutions you have that point to a given entity, any modification made will be made directly to the entity.
Since you are using CRM 2016 you have the possibility of choosing which fields from an entity to include in your solution. This could be used if you for some reason really want to have one solution with and one solution without your newly added field.
MSDN has the following note about having multiple solutions with shared components:
Some components can be included in more than one solution as long as
any changes that were made to them are compatible with all other
solutions that use them. It is important that all the solutions share
the same solution publisher. If the solution publisher is not
identical, organizations will not be able to install more than one of
your solutions.
we are currently using the DTAP (Development, Testing, Acceptance and Production) model in our Dynamics CRM 2011 environment. In the ideal situation we use solutions to be installed on each environment, however it occurs that manual adaptions are also performed.
To guard the data model, I want to create a "base line" data model which we can use to validate against after each deployment. There are managed 3rd party solutions and unmanned solutions in the system.
I have already used the solution packager from the CRM SDK to extract the solutions and then compare the content using WinMerge/Windiff (plain xml compare). I also used http://crmcustomcompare.codeplex.com, but this is not satisfying and using the metadata browser is very work intensive.
I wonder if there are other ways to guard the data model in the DTAP street of CRM.
If all you care about are the entities and attributes, the early bound generator combined with a diff tool does a great job of showing where things have changed.
Before: We had (still working) a couple of CRM 4.0 servers working: A productive one and a test one. We would perform any changes on the test server first and, after testing, replicate them in the productive server. For entities (custom or not) this would mean using the "Export Customizations"/"Import Customizations" functionalities. Pretty straight-forward stuff.
Now: we're testing CRM 2013 and trying to do the same with a couple of servers. We set up our data structure by hand (took some time) including the creation of all our custom entities, which are not few in number.
My question then is: How can I perform a bulk entity export-import in the same manner as it was with 4.0? I've tried selecting saving the entities to a Solution package, export the package from one server and import it onto the other. System entities feature in the target-server's import list but not the custom entities! And they are a part of the original solution packet (both checking it through CRM itself or the package file's XML code directly)
The lack of online help on this may imply that I'm not approaching this in the right way and I presume this is something already standard in CRM 2011.
Can someone give me a hint?
Thanks in advance!
Ok, I have no time to delve into reasons and explanations but things got solved.
I tried to export ONLY the custom entities and their related entities and it ended up working out.
Afterwards, trying again to export ALL entities ended up working just fine!
Therefore, i'm still not fully convinced I was not doing anything wrong. Most likely I just missed some essential basic small step or detail no one thought of due to it's "self-evident" nature.
(I guess being too stuck to CRM 4.0's "modus operandi" takes it's toll when updating...)
I'm looking into upgrading a .net 2.0 app. The app is used by the public authorities of a certain city to keep track of expenses and generate reports and forms.
The reports and forms were generated in VS2005 using Crystal report. They follow a well defined layout, like official documents usually do.
I am looking at options to upgrade the application and the main problem I have is in determining how to deal with the crystal report files.
I have successfully upgraded to VS2008, but any version after that doesn't have CR anymore, so my company would have to pruchase CR separately and because the client and my company are both tight, I'm looking at alternatives...
The obvious one is using SSRS. I have never touched it before in my life, but after playing around with it for a bit, I get the impression that it is not very well suited to generating forms with lots of non-tabular content and lots of formatting. Or am I wrong?
It seems that every line has to be drawn separately. There is no (that I can see) accurate way of positioning lines for formatting...
But I'm just a beginner, so I might be getting this all wrong?
If that is the case, are there any other alternatives to CR and SSRS?
I was thinking of maybe having a separate MVC web site project in the solution. Have that generate the layout in html and css with data from my entity model, then view the result in a (built-in or not) web browser. Am I overcomplicating on this?
I really need advice from somebody who's done that kind of thing before.
What SSRS is good for:
Talking to SQL Server, much faster than other products as it in many cases retains the database better when in other programs IMHO they repeat query at times.
Designing collapsable grids and chart objects from datasets. You can have 'groups' that can nest aggregates of collapsed values and can be un collapsed or collapsed on demand based on expressions, parameters, or a recusive parent set.
A web service for deployment ease where you can deploy one or many objects. You can also write add ons for this service with C# and the ReportingService.asmx web service.
You can talk to the web service directly in a 'form' object in HTML and manipulate it's output.
You can schedule reports to send out via email and file saves automatically to clients or internal users.
What SSRS IS NOT GOOD FOR:
It is not event driven hardly at all except for parameters. You cannot click on many things and get other parts on the form itself to update. You may do an 'action' that goes to another location, report, or site. But in essence you are calling a seperate object, not the same instance again.
Multiple layers of reporting. Beyond tweaking tool tips you cannot do 'hover over' reporting without hacking SSRS. You can make javascript windows show other reports but it is not baked in to SSRS. So you are either clicking into new reports or tab stops in a report but not getting hover over quick objects beyond text and expressions that are in tool tips.
What do you want before considering what you need to impement?
I want to input and export things while talking to my database - ASP.NET with potentially HTML 5 or MVC4 if you want to be very new. ASP.NET is made for actively talking to a server and taking commands IN as well as OUT.
I want a form to auto update periodically on a page as a landing site and dashboard - AJAX and Javascript on top of HTML, Java or ASP.NET.
I want to create reports that exist on a Server and can be hosted on a wide variety of platforms in .NET via web service calls - SSRS.
SSRS's biggest selling point to me is it's reusability once you dial a report in. They are pretty easy to create, easy to configure, easy to deploy, and if you get a little advanced in calling the webservice you can get SSRS report objects in other technologies if you want.
There is Crystal reports for VS2010 and VS2012. It is just not shipped with them. You can download the installation from here: http://scn.sap.com/docs/DOC-7824
I am running through the same decision process at this time. There is a .NET product from a company called "Windward" that will allow you to design your reports in Microsoft Office. If you are in the MS ecosystem already or want your users to design reports instead of always calling on you, this might help.
Their template design tool is called AutoTag and you can deploy these template to their .NET based engine in a few lines of code.
I know the question is regarding SSRS vs. Crystal comparison but thought you should know there are other alternatives and some can make life easier
Ryan
I'm just learning how to develop an application for Sharepoint.
As far as I can see there are three types of integration into Sharepoint possible:
Sandboxed Solution (limited resource access but easy to install etc)
Farm Solution (installation only available from administrator)
Standard application (maybe .net MVC) with referencing the Sharepoint assembly to access the SPS functionality
Is that correct and complete or am I missing something?
There are quite a few ways to develop for SharePoint depending on your scope, requirements, etc. My knowledge is more in the SP2007 realm than 2010 and my answer reflects that.
JavaScript
Using Content Editor Web Parts you can customize the look of SharePoint, interact with List Data and do some interesting UI effects just using jQuery and the SPServices Plugin. These solutions don't require package and deployment.
Custom Content Type
These can be created through the SharePoint UI or defined through custom XML documents and deployed via WSP. Essentially these are just a collection of field definitions that are related in some logical way. Content types can be added to a list to have all the fields automatically available. In addition, they provide a convenient way of mixing and matching data in the same list (think of roll-ups or backing up list data) though I've never used them in this way.
Event Receiver
Event Receivers can be created to respond to specific events in SharePoint. If you attach an Event Receiver to a list, you can listen for and respond to events like an item or attachment being added, updated, deleted in both a synchronous (-ing) fashion - so you can implement validation and cancel the operation - or asynchronously (-ed) - to do some post-processing once SharePoint is done processing the item. Event Receivers are processed by the Front-End SharePoint server which handled the request which triggered the event. This is different than Timer Jobs and Workflows which are executed by any server in the farm that happens to be available.
Further, Event Receivers can be attached to lists based on their type (apply to all lists of this ID type) or they can be associated with a Content Type and become associated with a list that way (when the content type is added to the list, so too is the event receiver added).
Feature Receivers are a special kind of Event Receiver in that they respond to a Feature
being activated or deactivated to do some additional work. Many people refer to this extra work as Feature Stapling since it lets you perform additional tasks on-demand that couldn't otherwise be done using just XML documents.
Timer Job
A Timer Job is a piece of code that is run on a schedule. It's not executed in the W3WP process like Event Receivers are but rather via the TimerService. Because of this, certain features or values are missing from the SPRequest object. Developing Timer Jobs is more difficult and, in practice, more error prone, more difficult to debug, etc. than Event Receivers.
Workflow
Workflows can be created using SharePoint Designer or Visual Studio. The major difference between these are features available to you at design time. SharePoint Designer Workflows are easier to create and get going but tend to be buggy in SharePoint 2007. Further they are not easily packaged and deployed across environments but rather are associated directly to the list in which you created them (in 2007; in 2010 there is extended capability to allow packaging or even migration into Visual Studio for more complicated customization).
Using Visual Studio gives you more depth and capability but like Timer Jobs they are often difficult to "get right" and they are also processed by the Timer Service process.
Web Part
A custom Web Part is very similar to a regular ASP.NET web part with some extended capability within the SharePoint context. You have access to the SPRequest object and thus all the contextual information (current user, current list/web/site, etc.) to do your work. You can access external databases, make use of most ASP.NET controls, etc.
Custom ASPX Page
If a Web Part isn't sufficient for your needs or you want control over the full page, you can create SharePoint-enabled web pages. These are standard ASP.NET pages decorated with the proper SharePoint master page and deployed into a subdirectory of the hive LAYOUTS directory. With this you have similar access to the current request state as with a Web Part but you have more control over the entire page render.
Custom Web Application
If you have need for a standalone application, you can still take advantage of SharePoint's authentication and authorization tools without running directly in its context. To do this, create an IIS Web Application and set the Application Pool Identity to the same as SharePoint. Alternatively you could make a virtual directory within your SharePoint application pool but this is generally not recommended. You will still be constrained to using the .NET Framework 2.0 runtime if you want to use the SharePoint Object Model at all. This setup seems rarely used in the field since most of the time you can accomplish your needs by just using custom ASPX pages or web parts.
Regarding your specific questions:
Sandboxed solutions are just a special type of solution that restricts the namespaces your web part, etc. have access to. For instance your code can't reach out to access lists outside of its permission area. It can't send email on your behalf. You can increase your rights by using custom permission sets but this is an advanced topic. I just wanted to point out "sandboxed solution" isn't a type in and of itself, it just describes a restriction where previously none existed (SP 2007 GAC-deployed solutions).
Regarding your question regarding an MVC application using the SharePoint Object Model, like I mentioned you are still restricted to running in .NET 2.0 runtime.
EDIT: I forgot (at least) one more option!
List Service / Other ASMX Services
SharePoint has a number of web services you can consume to interact with Lists among other things. In this case, your application can be developed using any technology (or runtime!) you wish as long as it knows how to consume the ASMX services. The functionality available isn't as rich as using the Object Model directly (which is why I often forget to consider it) but it does allow your code to be more decoupled from the SharePoint environment itself. In 2010 there are a lot more options for Client Services to provide even greater functionality.
For developing a solution in visual studio you can go for Sandbox solution and farm solution. If you are having SharePoint 2013, then you will have another better option which is App Part development.
Since Sandbox solution is depricated from SharePoint 2013 onwards, i suggest you should not go with Sandbox solutions. Better to go with App Part development.