There is one requirement to create a default attribute say 'Test' on creation of an entity like we have Owner field common in every entity in CRM 2011. Can you please help me in this?
The easiest codeless solution is to have a workflow fire on create of your record. The value won't appear straight away but it will always be set.
There is no supported way to allow automatic creation of a new metadata attribute on an entity, that is triggered by the creation of the entity itself (it is not possible to register a plugin against the creation of an entity). My recommendation is that given the (surely) rare incidence of entity creation, remember to add the custom attribute yourself. This will undoubtedly take you less time than trying to hack an automated workaround.
Edit:
I still stand by disuading you to do this in an automated way, however as a trigger point you might consider harnessing the publish or publishall message as a way to fire a custom plug-in (as per my note below).
Related
My client have asked me to delete a custom entity and its dependencies (which prevents deletion of this entity) programmatically.
I have retrieved the dependencies of the custom entity using RetrieveDependenciesForDeleteRequest. This request is giving me the collection of dependencies, which must be deleted before the deletion of that custom entity.
RetrieveDependenciesForDeleteResponse resp =
(RetrieveDependenciesForDeleteResponse) service.Execute(req);
//A more complete report requires more code
foreach (Entity dependencyEntity in resp.EntityCollection.Entities)
{
service.Delete(d.LogicalName, dependencyEntity.Id);
}
Now the issue I am facing here is that dependencyEntity.Id is always empty GUID, instead of valid GUID.
Can some one help me how to achieve this functionality?
The Entity items in the response merely act as data transport objects. They are not real entities. What you are looking for is the attribute named "dependentcomponentobjectid" (this is a Guid type, not an EntityReference). Attribute "dependentcomponenttype" (OptionSetValue) gives you a clue about the type of the component you are dealing with.
Note that a dependentcomponent can in turn be a required component other components are depending on. (E.g. a workflow depends on a workflow activity, which in turn depends on a plugin assembly.) So, a robust removal tool would need to follow a recursive strategy.
I'm deleting an instance of an entity and depending on the value of an option set in it, I wish to carry our different course of action. The problem is that the field isn't changed, hence, not provided to the plugin's target.
How can I easily tell the stupid plugin to fetch all the fields?
The way I do it now is to use pre-image but I'll be showing the plugin to some rookies and they will definitely not like it. And they won't believe me that's the way to go, for sure, because they're a cocky bunch.
Is there a work-around for that?
Using the pre-image is the suggested way in this scenario, the alternative is to instantiate a service factory in order to get an IOrganizationService and retrieve the entity using the target's Id.
It is part of the IPluginExecutionContext (of which Target is one part.) I think the beginners are confused if they think of Target as anything more than a property of IPluginExecutionContext.
It wouldn't make sense to have these values as part of Target, because then it would cause an update of the field to its current value - if you forced it into Target you would see the update in the audit details.
Thus, CRM has PreEntityImages, Target, and PostEntityImages, if Target was used the way "they" want it would not be able to differentiate between values being updated, previous values, and the final result of the entity.
This question may have already been asked, sorry
I'm looking at the architecture for validating our model. Our simple validation can be achieved by using the property validation attributes (some custom) and using
ModelState.IsValid
however the problem is when validation requires access to the database or access to another property. A perfect example is to check for duplicate names. In this case we need to check the database for duplicate names where the id is not equal to that of the current object (for updates)
If we were to write this as an validation attribute to be applied to the name property this would cause to problems. Ome how do we get access to the database and two how would we get access to the id property.
So in conclusion. Is there any examples of good ways to architect a fix to this problem?
I spent some time exploring this today for a project I was working on and came to these conclusions.
It is not to bad to solve the how, much of it involves some reflection and using the validation context to inspect and access other properties of your model or using IValidationObject. The real question becomes is it okay to do validation that requires database interaction.
For one I was concerned about performance, in one particular case a validation made a query that returned an object to ensure it existed which I later needed for relationship assignment which would then cause another query.
Secondly you need to think about database concurrency. The best way to do duplication checks is during insert not before because the database could change between the two operations. This also relates to the first reason, an object could be deleted immediately after a database reported it exists.
In my particular project I felt it better to keep this sort of behavior with modifying my EF context and adding anything that went wrong to the ModelState.
We're looking for a way to document Core Data entities. So far the only real options I've come up with are:
Document externally using UML or some other standard
Create NSManagedObject subclasses for every entity and use code comments
Use the User Info dictionary to create a key value pair that holds a string comment
Option 1 feels like too much extra work and something that will almost certainly be out of date 99% of the time.
Option 2 feels natural and more correct than option 1. The biggest con here is that those comments could potentially be lost if this model class is regenerated using Xcode.
Option 3 feels a little less correct than option 2, but has the added advantage of adding automation possibilities with regards to meta data extraction. For instance, in one of our apps we need to keep a real close eye on what we're storing locally on the device as well as syncing to iCloud. Using the user info dictionary it's pretty easy to automate the creation of some form of artefact which can be checked both internally and externally (by the client) for compliance
So my question is whether it would be inappropriate to use the user info dictionary for this purpose? And are there any other options I'm missing?
Option 2 is what I use every time. If you look at your core data model (something.xcdatamodeld or something.xcdatamodel) you will see something like the picture below.
You can tie your entity to whatever class you want and then put the comments in there. It helps if you keep your entity name the same as your class name to make it obvious what you've done.
Additionally this also gives you the ability to add automation. You can do this by creating custom getters and setters (accessor methods) and a custom description method.
I use option 2 and categories. I'll let XCode generate the NSManagedObject subclasses and use a categorie on each of these subclasses. With the categories I do not loose my changes made in the categories, can document, make custom getter and setters and I am still able to use generated subclasses.
If we speak only about documenting (i.e. writing more or less large amounts of text which is intended to be read by humans) your classes, I'd use the option 2.
If you are concerned with the possibility of Xcode overwriting your classes in the option 2, you may consider creating two classes for each entity: one which is generated by Xcode and always could be replaced (you generally do not touch this file) and one other which inherits from the generated one and in which you put all your customizations and comments.
This two-class approach is proposed by the mogenerator.
Although if you need to store some metadata with the entities which will be processed programmatically, the userInfo is perfectly suitable for this.
Versioning
If your events changes you would create a new version of that event, and keep the old ones. To keep your domain code form being bloated with handling of all versions of events you would basically introduce a component that converts your events from previous to newer versions, and then apply them on the domain. Remember that events are things that actually happened in your domain so in most cases the information in deprecated events are valuable.
I still haven't found any example of this.
Any help?
There are two main ways to handle event conversions. Both happen during event deserialization :
You can add new classes with version numbers (SomethingHappened, SomethingHappened2, SomethingHappened3). The deserializer will instanciate and populate the class, the pass it to a converter to get the same event in its higher version, here SomethingHappened3.
One of the problem is that you'll have to update also event handlers to use the last version of the event.
To mitigate this, you can use a convention that SomethingHappened is always the last version. When going to v2, rename SomethingHappened as SomethingHappened1 and create a SomethingHappened that will be the v2. To do that you need to have control on the classes created from serialized event since the serialized class name will not contain the version number, you should store it aside.
Instead keeping every version of the classes in your code, the converter will receive a Document (a tree, like an Xml document or JSon object) and will modify it to provide information needed to build the last version.
All this depends on the control you have on your deserialization pipeline.