When I upgraded by blog site last month, I left out some code that prevented postings from the Meandering category from being distributed via RSS.
I put that code back in and this is a test.
If you're going to the WWPC in Houston next month, drop me a note. mitch at infinite-x dot net.
I'll be there all week so maybe we can meet up in the CRM Community Lounge.
Hopefully, my schedule will not be nearly as hectic as it was at Convergence.
I have been battling bugs in other people's software all morning when I received and email from 'Kim.'
Get your corn really big!
Be the center of the world!
Be the MAN!
Wow! Now that put me in a better mood….
For the record 'Kim:'
I live in Coppell, Texas. We don't have any corn.
I thought the center of the world was somewhere in England.
I pee standing up, which, the last time I checked, kinda sorta mostly makes me a man.
Sheez.
I got a serious case of writers-block this morning. I'm not sure, but maybe it was caused by showing up to the office at 6:45am on a Saturday. I dunno.
Anyway, I decided to take a break from latest monster invention and browsed around he Internet for a while, reading blogs and such. I ran across a set of quotes by Jazz musicians on Matt Mullenweg's ( WordPress' creator ) blog and found one by Duke Ellington that kinda, sorta, mostly, seemed apropos:
"I merely took the energy it takes to pout and wrote some blues."
Exactly the thought that I needed to get my lazy ass back to work.
Uh, right after my nap, of course
Peace out.
Back in the dark ages, like with CRM 3.0, we were often faced with writing .NET code to provide certain enhanced data manipulation capabilities as either Callouts or Workflow Assemblies. CRM 4.0 totally changes that mind set – and as a solution developer, you really need to keep that in mind before you jump off into the depths of Visual Studio and the CRM SDK.
An Example
To illustrate my point, let's take the PostInvoicePlugin example from the CRM SDK ( v4.0.5 ).
Note: this example is found in the SDK folder: sdkserverfullsamplepluginpostinvoice
The purpose of this sample code is to show you how to update a custom field on the Account record whenever a user closes out an Invoice as Paid. The plugin checks the state of the Invoice, and if Paid, it will update the value of a custom field on Account, using the following code:
// If the Total Invoiced exists, update it... otherwise set it if (parentAccount.Properties.Contains("new_totalinvoiced")) { ((CrmMoney)parentAccount.Properties["new_totalinvoiced"]).Value += totalAmount; } else { parentAccount.Properties.Add(new CrmMoneyProperty("new_totalinvoiced",
new CrmMoney(totalAmount))); }
Pretty cool, huh?
An Alternative
If you haven't spent much time reviewing CRM 4.0 workflows, you should. You can perform some amazing things without ever writing code. Let's perform the exact same steps using CRM 4.0 workflow.
First, we create a workflow based on the Invoice Entity that has the following properties:
Step 1:
Create a Check Condition using the following information:
Step 2:
Add and Update Record step, on the Related Entity Customer (Account):
Step 3:
Click the Set Properties button, then set the Total Invoiced Attribute to the following:
Note: Total Invoiced is a custom Money Field.
By using the Increment by Operator, we are able to increment any existing Total Invoiced amount by the amount found in the Invoice's Total Amount field.
Final Step:
Save and Publish this workflow.
Conclusion:
So, is there a difference between these techniques? Not really. Both accomplish the job in a very similar manner but the Workflow solution requires zero code maintenance and a normal user or administrator can create the workflow.
The biggest difference between the two techniques is in the timing of the actual update. Plugins can be executed either Synchronously or Asynchronously. Workflows function in an asynchronous manner.
The Synchronous operation will modify the data stream as it is being saved to the database, which can introduce a delay in the user's experience, but will provide results back to the user in a quicker fashion.
Asynchronous operations will happen shortly after the data has been saved which will not impact the user, but which may result in a slight delay between the time the user saved the record and when the value will be updated.
If you can live with the time delay, I feel that workflow is the way to go, in most cases. If you can't, then download the SDK and start working through their examples.
One of my current projects involves a heavily customized Opportunity form and I was running into the following error messages whenever I attempted to set the value of a custom Attribute which was of a Money type:
A currency is required if a value exists in a money field. Select a currency and try again.
The solution, believe it or not, is stated right there in the error message:
You must select a Currency before you can populate any Money field.
I thought this was a rather odd behavior, until I realized the root cause of issue.
I was testing out my calculation, which involved three form fields, within the Form Preview ( Create, to be exact ). It turns out that the Currency is not automatically populated during the Preview, so my attempt to set a Money field was failing.
Once published, and operated normally, the Currency field is populated with the default currency as specified for/by the user.
Just to be safe, I added the transactioncurrencyid Attribute to the list of Attributes that must be completed before the calculation will be performed.




