Similar to Entity Framework I would like to know if there is a tool or nuget package I can use where I can just send the Dynamics URL and credentials in order to create object models from a Dynamics System. I'm trying to avoid creating custom DTOs.
You can use CrmSvcUtil to generate strongly-typed classes for entities.
Command line:
CrmSvcUtil.exe /url:http://<serverName>/<organizationName>/XRMServices/2011/Organization.svc /out:<outputFilename>.cs /username:<username> /password:<password> /domain:<domainName> /namespace:<outputNamespace> /serviceContextName:<serviceContextName>
GUI: (by Daryl from community)
Early Bound Generator in XrmToolbox & its video tutorial + documentation
Early Bound Generator included in the XrmToolbox is the simplest. https://www.xrmtoolbox.com/
Find the right configuration then take the command line and include it in a batch file under source control. You'll have to run it each time you add fields in CRM, depending on your needs. If you lose your starting configuration, your code might not be compatible the next time you generate.
Related
I am using Microsoft Dynamics CRM 2015 on-premise version.
Im importing my solution to an other organization with custom entities and workflows.
I created a workflow to do some work depending on the type of the inserted queueitem.
My issue: Some conditions in my imported workflow are not supported in the new organisation (only the conditions on the custom entities are not supported and are replaced by empty brackets)
I think the custom entities IDs are not imported with the same values, so, the CRM does not recognize these custom entities condition.
Try exporting and importing the customization in two separate solutions.
In the first solution include the entities and optionsets you wish to import. Export the solution from the old environment, import into the the new environment and publish.
In the second solution include the workflows. Oncce again export the solution from the old environment, import into the the new environment and publish.
When you point to an entity inside a workflow, it will retain the GUID.
If you export/import the workflow, the reference will be lost because that specific GUID won't exist in the new environment.
The issue is indeed that the GUID values of the records referenced in your workflows are passed trough the solution but doesn't exist in your target environment.
You can either:
Modify you workflows, instead of (for example) Primary Entity Opportunity / Account / Equals / Contoso use Related Entity Account / Account Number / Equals / ContosoNumber
Import the data referenced in your workflows by keeping the same GUIDs. This is slightly more technical:
First, you need to export the data from your source organization (either SQL or Export to Excel with reimport enabled)
Then convert this file to csv while keeping the id value embeded
Reimport the file with import wizard and mapping the GUID column
I have a requirement to read excel file using tibco palettes.Can any body please throw some lights regarding this. I am basically new to this tibco BW. Please tell me what steps should I follow?
I am assuming you are not referring to CSV files, for which you could use the File Read and Parse activities of BW.
If you want to parse or render a multi-worksheet workbook, you can try publicly available API's such as Apache's POI or commercial API's such as from Aspose to cut your own Java based solution. Then you can use the Java Code or general Java activities to embed and use that code.
And then there's another ready-to-use option available from us: an Excel Plugin for TIBCO BusinessWorks, if you wish to leverage all built-in features of BW (XPath mapping, etc) when parsing or rendering your Excel.
Edit 1:
As per your comment, you can also try the following steps, if you are looking for a more homegrown solution.
Based on one of the (public/commercial) libraries above you can write generic Java Code to parse each cell of each row of each sheet of the workbook. Output should be an XML string. Then create an XSD to match your output. It is at your discretion, which information of the cell you want to read from the workbook - you already are aware of the complexity of the API, I am sure.
Create a BW (sub)process that calls your code from a Java activity, use Parse XML to parse your XML string result into you XSD structure. Configure the End activity to use your XSD and map (copy) your Parse XML result into the End activity.
Then wrap this subprocess into a Custom Activity (General Activities Palette). Create a Custom Palette and now you can re-use what you did in many other BW projects. The path to the custom palettes can be found in TIBCO Designer - Edit- Preferences - General - User Directories
If you add Error Output schemas, you will also get typed error outputs from that custom activity.
HTH,
Hendrik
The title says it all really. I've found several blogs with different ways (serializing the EF model to XML and then de-serializing again to the IEdmModel was one) but they're all based on old version of the OData package.
Serializing is the only way.
Example.
Relevant work.
I've ranted about this a few months ago. AFAIK nothing changed since then, and I personally don't expect them to change too much. The short story is that as of September 2012, there is no plan to use EdmLib in EF, nor is there to use EF's code in other projects.
How much should we align with OData’s EdmLib?
Not worth adopting code
Cost of implementing SSDL & MSL
Freedom to evolve our API independently
Look at aligning names of types and properties where appropriate
If your DbContext is being built from a database-first approach the given answer will fail giving this error:
Creating a DbModelBuilder or writing the EDMX from a DbContext created using Database First or Model First is not supported. EDMX can only be obtained from a Code First DbContext created without using an existing DbCompiledModel.
After some time messing with this I have found an appropriate solution. Basically you grab the CSDL resource from the assembly containing the DbContext in question and parse it using the Microsoft.Data.Edm.Csdl.CsdlReader.TryParse method. The resulting IEdmModel is valid containing the exact information given by EntityFramework when the model was built.
See here for an example with usage
I am currently working on a ASP.NET MVC 3 project and I am setting up the solution file on VS2010.
I am not sure of what is the standard approach. I am using the following approach
Company.Dept.Data (contains the dbml file - Data Model)
Company.Dept.Business (Business logics)
Company.Dept.Web (contains ASP.NET MVC3 webapplication)
The first two are class libraries and the last one is MVC3 web application.
Anyother recommendations?
There is no single "standard" approach. It all depends on your project and what problems you are trying to solve with the software. Your proposed structure of having 2 class libraries and 1 web project is one way to go for sure.
If you are going to do any kind of Dependency Injection using an Inversion of Control container, you might also want to consider having an "API" project for interfaces and an "Impl(ementation)" project for concrete classes that fulfill the interface contracts.
To echo danludwig, there really is no standard. I prefer breaking up libraries and namespaces according to functionality. Company.Db is my library for interacting with the database, Company.Mail are my wrappers around the Postmark mail service, etc.
I then tend to group like libraries into single repositories. So the 'storage' repository in source control holds Company.Db, Company.Caching, Company.FileStorage, etc. I have another repository 'messaging' that holds Company.Mail and Company.SMS (for interacting with Twilio to send text messages). When I branch out with new apps or new services (maybe a WCF endpoint for mobile clients), I can just pull down the 'messaging' repository, and I have all my class libraries for communicating with the user.
An application then looks like
Company.Application.Webite
\Libraries\Messaging
\Libraries\Messaging\Company.Mail
\Libraries\Storage
\Libraries\Messaging\Company.Db
\Libraries\Messaging\Company.Caching
\Libraries\Web
...
Company.Application.Wcf
\Libraries\Messaging
\Libraries\Storage
\Libraries\Messaging\Company.Db
\Libraries\Messaging\Company.Caching
...
This way, whether someone registers via the site, or via the mobile app, Company.Mail.MailServices.SendWelcomeEmail() sends the exact same welcome email, and there's no code duplication.
Whether this works for you, or even makes sense, who knows. I've also changed this scheme a hundred times, trying to find a layout that works with my development style/workflow. I wouldn't worry or stress too much about it, because whatever you pick, you're going to find things you like about it, and you'll find things you hate about it. I sometimes fall into the trap of spending more time trying to make everything "perfect", than to just code and change things I don't like.
I have created a custom entity in MS CRM 4.0 and am trying to update a couple of the attributes via a custom worflow in .Net. I have read through several of the forums and blog posts and am still confused on how to access the custom entity and update some of their attributes.
I created a custom entity to replace how CRM was doing allotments as our company has some specific business rules that CRM wasn't doing. When a task is completed on an incident I want to update an attribute in the custom entity with the task duration. Any help would be greatly appreciated.
Thanks
When using the CRM web service in a custom workflow, you'll need to use DynamicEntity objects. The workflow context webservice is just an ICrmService so it doesn't know about your specific customizations. There's a pretty sample here: http://www.stunnware.com/crm2/topic.aspx?id=CustomWorkflowActivity
I imagine you could also add the CRM web services as a web reference to your workflow project. Then you'd have strongly types objects for your custom entities. I've never done this for my custom workflows, but it works for other custom apps accessing CRM.
Choosing Dynamic Entities over WSDL in favour is always the better choice.
When you develop a piece of code, you are more flexible with your classes. You could use your piece of software in different contexts for different systems. That's the reason Dynamic Entities were invented.
It's very easy and you dont'have to use DynamicEntity. You have to go to Settings -> Customization -> Download WSDL. Take the wsdl and use it in your project. Now you have all your custom entities strongly typed. All you have to do is to write something like this:
Guid entityId = getEntityId();
new_yourCustomEntity entity = new new_yourCustomEntity();
entity.new_yourCustomEntityid = entityId;
entity.new_customProperty = "value";
CrmService crmService = new CrmService();
crmService.Update(entity);
Maybe what you really mean is Custom Workflow Activity? This involves writing your own .NET class to add functionality to the standard CRM WF in form of new step types. If what you want to do is just to update an attribute you don't really need this, even if it is on a custom entity. The Update record step does just this and allows dynamic values (coming from other entities) to be specified.
Hope it helps
Daniel