Tuesday, February 25, 2014

Arduino: The Universal Circuit

A bit of a departure from my usual topics but one which may well be of interest to like-minded folk. For a while I had heard about some kind of electronic doodad called an Arduino circuit. I never really understood what they did or how they could be relevant to me. Thanks to a Christmas purchase I now see the light and I am dusting off my coding fingers.

Old School Electronics Kits

As a kid, I had an old electronics kit. The connectors were springs which you bent to the side and shoved your wire between the rings. It came with a book of electronics projects. I even found a picture of it online.

My memory of this kit is spending hours running the connections in the book only to have it do very little when I threw the switch. Occasionally, a project would work but, even when it did, the wiring was so complex it was difficult to understand what was going on.

In Australia, we also had the “Dick Smith Electronics” kits. These were packets of electronic components you put together to create something e.g. the Knight Rider flashing LED kit or an FM transmitter. These were fun and educational but are no longer with us. Dick Smith Electronics went into retail and their kits are now a fond memory of Generation X electrical engineers.

Principle of Equivalence of Hardware and Software

To understand the evolution to Arduino, let us revisit some computing theory, specifically the Principle of Equivalence of Hardware and Software which basically states “anything you can do in hardware, you can do in software and vice versa”. As an example, we will consider a classic of the electronic set, the light bulb whose brightness varies based on the ambient light, as measured by a photo-resisistor (something whose resistance changes with the light it receives).

In our circuit we will have the photo-resistor, a light bulb and some clever arrangement of relays and/or transisitors and maybe some diodes to take the input of the photo-resisitor and transform this into a moderated current for the light bulb (we could probably make the circuit with a simple voltage divider in this case, but let us pretend).

The idea behind the Principleof Equivalence is we could also get our input (photo-resisitor) and output (light bulb) and link then via a processor running some software and generate the same result.

The Makey Makey

Now let us come to my Christmas present, which made everything clear; a Makey Makey. This is a cute device that plugs into your computer and lets you turn anything slightly conductive into a arrow key, mouse click or space bar.

I played with it for a bit, got the kids excited and on reading the web site, it informed me that when I wanted to take things further, the Makey Makey could be turned into an Arduino. From there it all fell into place.

In this case, the Makey Makey takes the input of closing a circuit by touching, say, a piece of fruit and converts this into the output of a keyboard key-press, via what is called a micro-controller (a small computer running code).

The Arduino

The Arduino is what the Makey Makey is based on. It has input and output ports, the micro-controller and a USB port so you can hook it up to your computer to power it and also to download your code into the micro-controller.

Luckily for me, the Arduino is programmed using C/C++ which is what I used to write back in my university days when coding physics simulation programs on Linux boxes. Here is the classic “hello world” sketch (what programs are called for Arduinos) for the Arduino which makes the on-board LED blink.

 

#define LED_PIN 13

void setup () {
pinMode (LED_PIN, OUTPUT); // Enable pin 13 for digital output
}

void loop () {
digitalWrite (LED_PIN, HIGH); // Turn on the LED
delay (1000); // Wait one second (1000 milliseconds)
digitalWrite (LED_PIN, LOW); // Turn off the LED
delay (1000); // Wait one second
}

 

This very readable code. In this case we only use one ‘pin’, number 13, as an output with no input. You write these programs in a free program you download onto your computer which also handles the uploading into the micro-controller via a button press.

My Project List and Tutorials

I already have my list of projects lined up:

  • A USB control panel for a Mame arcade emulator, using my Surface for the screen
  • Laser harp
  • Theremin using proximity sensors
  • Convertor for a traditional typewriter to make it usable as a full keyboard

but before I do these I am going through a series of tutorials on Arduinos on YouTube by Jeremy Blum. These are proving very useful for learning the practicalities of circuit design e.g. switch-bouncing and pull-up/down resisitors compared to my very theoretical knowledge of electrical circuits. It is also giving me a good idea of the parts I need for my kit.

How to Buy an Arduino and its Parts

I have bought my Arduino and the various parts to go with it (LEDs, a breadboard etc.) almost exclusively on eBay. A breadboard means there is no soldering which is also a big improvement on my old electronics days as a kid. The Arduino board can be bought for $10-20 and the other bits and pieces cost pennies. This is one hobby which can be explored without breaking the bank.

There are also pre-made add-ons for the Arduino called ‘Shields’ which plug onto the top of the Arduino board providing additional functionality e.g. GPS shields, ethernet shields etc.

Conclusions

Obviously not a CRM post but all work and no play makes for a grumpy IT worker so, if you are looking for a hobby which plays to your technical strengths and you always wanted to automate your home like Bill Gates then here is the chance. An Arduino and parts will cost about the price of a bargain box computer game and provide unlimited creative opportunity.

Have fun!

Saturday, February 15, 2014

Developer Essentials for the Functional Consultant

I am the first to admit I am not much of a coder. The only time I really put code to screen is for my new hobby of Arduino sketching (another blog coming soon). However, to be an effective functional consultant I still need to know the basics to make sure I am not expecting too much of the coders; there is no point documenting a design where one small element will take six months of development when an alternative approach will take half a day.

It is true that a good developer will push back on a bad design and suggest a better approach but, if a functional consultant knows the basics, they can steer the client down the right path to begin with and avoid disappointment later.

In this blog I will cover the two most common tools in the development kit-bag; jscripts and plugins. Please note this is not a comprehensive guide to developing in Dynamics CRM. For detailed information, consult the excellent SDK. If there are any developers reading this and I trip over a term or make a hash of something, please do add it to the comments. I would prefer to look foolish and learn something than lead the readers astray ;)

jscripts

jscripts operate within the browser and, in my experience, commonly serve two purposes:

  • Make stuff happen on an entity form e.g. pop up a warning on the create form of a record
  • Do something when a custom ribbon button is pressed (2011 terminology, in 2013 we have no ribbon but the actions remain)

In terms of the form, there are four events you can fire the jscript off:

  • OnSave (saving of the form)
  • OnLoad (when the form opens on the screen)
  • OnChange (when the value in a field changes)
  • TabStateChange (opening and closing of Tabs)

For buttons, we can fire the script when someone presses our custom ribbon button. This can be useful as an interim step for doing something else e.g. firing a workflow/dialog or plugin (plugins are a little trickier because the server is oblivious to the jscript doing things, and plugins work on the server, but I will talk about how we get around that later).

The jscript does not care if the server knows about the change or not. So, for example, an OnChange script can do things on the form well before the form that is open has been saved. Also, jscripts fire immediately; there is no concept of pre or post-action; they just happen after the event occurs. Therefore, it makes sense not to overload a jscript with doing too much because it means the browser will get bogged down. For those of you who go to web sites where a warning pops up telling you a jscript is taking a long time to run, you will know how this feels.

CRM 2013 has done an excellent job of eliminating the need for a lot of common jscripts through the Business Rules function which allow an administrator to define field and form behaviours through configuration. Business Rules trigger off of field changes, or when the form opens, and allow for things like:

  • Popping up a message box
  • Changing the value of a field
  • Making a field compulsory
  • Setting the visibility of a field
  • Locking or unlocking a field

Therefore, if you are upgrading from CRM 2011 to 2013 or designing a CRM 2013 system, consider Business Rules to reduce development time.

Plugins

Plugins run on the server and provide a lot of flexibility and power. As they are server-side, they have no concept of CRM forms but simply respond to stuff that happens on the server. This can be through the saving of information on a form, through the web service layer or through the importing of data through the import wizard (strictly speaking, everything goes through the web service layer, but you get the idea).

Plugins do not trigger off of events, because events are something that happen on forms; plugins trigger off of messages happening in the back end of CRM. While jscripts get a few events to fire off, plugins get many, many messages to fire off. Jamie Miley, my roomie for the most recent MVP Summit and passionate freedom fighter did a great blog on the messages for CRM 2011 here and here (they are also available via the SDK). For CRM 2013, you can see all the messages in the SDK here. An example of a message is the ‘Create’ message for the Account entity. This means we can fire a plugin when the server knows about the creation of a new account.

Plugins can fire before or after the message i.e. a pre-plugin can prevent the creation of an account from occurring, and they can run synchronously or asynchronously meaning they do not have to hold up the user but can run in the background communicating and waiting for third party web services, for example.

Just as Business Rules have reduced the amount of jscript being written in CRM 2013, improvements to workflows mean these have also made in-roads in reducing plugins. Before CRM 2013, workflows ran asynchronously (in the background). While I am a big fan of workflows, only being able to run in the background made them a little awkward in some cases and downright impractical in others. With synchronous workflows in CRM 2013, they are a lot more powerful. A good example of this is the auto-numbering solution from last week. With asynchronous workflows there was always the potential for two workflows to fire close together and assign the same auto-number to two different records. As CRM MVP and fearless truth reporter, Jukka Niiranen recently showed, we can, with a strong level of confidence, rely on synchronous workflows to generate unique auto-numbers for records. Previously, robust behaviour like this was only possible with plugins.

Mixing Code and Helper Entities

This is a nice trick my comrade in arms, Olena Grischenko has shown me. It is one way to trigger a plugin from a ribbon button. The ribbon button can run a jscript and so we need a way for this to generate a message on the server. The trick is to create a new entity (a ‘helper’ entity) and have the jscript act on this entity in some way which the server knows about e.g. create a new record for this entity. This generates a message e.g. a create message and our plugin fires.

Conclusions

As a functional consultant, most of my work is concerned with the front end and adapting it to meet the needs of my client. However, sometimes I must resort to code to smooth out the rough edges or to meet a specific client requirement. In knowing the essentials of how code works with CRM, I can ensure I design the CRM system to be practical but also affordable. This makes for happier clients, happier developers but, most importantly, a better CRM system.

Saturday, February 8, 2014

Revisiting Workflows: Auto-Number

Back in 2010, I wrote how you can use workflows to create an auto-number counter for your records. Given the expanded functionality of workflows in CRM 2013, I thought it was a good time to revisit this solution to see if the new features make auto-numbering work even better.

Auto-Numbering Out of the Box

A little over three years ago, this is what we had in the, then beta, 2011 which was the same as what was available in version 4.

image

Today, we have a cleaner look but, functionally, auto-numbering has not changed one bit.

image

This is a shame but, thankfully we can overcome these shortcomings through workflows or, more commonly code. Codeplex also has a few options. Here is one I have used in the past with success.

Previous Workflow Problems

The biggest problem we had with workflows in previous versions of CRM was they were asynchronous. This meant they did not run straight away but got queued up and ran when the server decided (generally a few seconds later). This meant that, while we could build an auto-number tool with workflows, the number generated would not appear straight away and even if we closed and re-opened the form, if the workflow had not run, the number still would not appear.

With CRM 2013, we have synchronous workflows, which means they run straight away. We still need to refresh the form to see them but the new form behaviour of CRM 2013, this does not prove to be a problem.

The Structure

The structure for the counter is the same as the one from the previous blog (a new parent entity for Account holding a prefix and counter, and a workflow to make the magic happen). The main difference is we make the workflow run synchronously (by unselecting the ‘Run this workflow in the background’ tickbox).

image

In the previous version, I had trouble running the counter with one workflow but, this time it works fine and there are three steps:

  • Update Account (#1) – Linking the newly created Account record to the Counter record which defines the prefix and the current counter number value
  • Update Account (#2) – Modifies the Account Number field with the counter prefix and current counter value
  • Update Counter Record – Increments the current counter value by one

What We End Up With

The combination of a synchronous workflow and the form auto-refreshing on save means when hit the ‘New’ button, populate the fields and hit the Save button, our Account Number field is immediately populated; no reopening required.

image

One Last Improvement

One last thing you can do is make the Account Number field read-only. This can be achieved by going to the field properties on the form and ticking the read-only box.

image

or, for more exotic behaviour, you can use a Business Rule. In this example, we only lock the field once it is populated.

image

Conclusions

Asynchronous workflows, while easy to configure, always had shortcomings because you had to wait for them to complete. This meant, for the user, it was not always clear whether the workflow was happening and this had the potential to cause confusion.

With CRM 2013, we now have workflows which happen straight away and many of the previous ‘niggles’ have gone away. Combined with new features, such as Business Rules and the new Flow UI, processes are becoming more and more relevant for solving real-world business process problems, previously dealt with using jscripts and plugins.