Two posts, back to back?
I couldn’t help myself – I just needed to get a bit more information out about the Windows Azure Integration Pack… and, well, how it is unlike any other Integration Pack to date.
Why is it different?
Well, it was the first Integration Pack to take advantage of Cascading Dependencies. Because the Windows Azure Integration Pack was developed with the latest version of OIT (Orchestrator Integration Toolkit), the timing was right… the Product Team decided to leverage one of the coolest new additions to OIT with one of the coolest new Integration Packs!
So, what are Cascading Dependencies?
If you look here (Overview of Orchestrator Integration Toolkit), under the “What’s New in SP1”, you will find the following:
- For System Center 2012 SP1, users can have progressive disclosure of information based on settings they make within the activity.
- System Center 2012 SP1 supports custom dialog types.
Fair enough, but let’s dig a bit deeper… Oh! Here we go – If you look here (Cascading Dependencies in System Center 2012 Service Pack 1 (SP1)), you find the following (among much, much more information):
“The use of cascading dependencies greatly simplifies the user experience when configuring complex activities by reducing the amount of information from which the customer selects to only what is most relevant. You can also use this feature to include or exclude properties from display based on the selections in other properties. This is useful when certain properties either must be or cannot be used together.”
I guess the lesson here…if there is one – Make sure you bookmark this set of MSDN pages: Orchestrator SDK
Okay, enough typing! Show me the Demo!
NOTE: This post is somewhat significantly related to my most recent post, which can be found here: Automation–Orchestrating Windows Azure–Solving the Public Cloud Puzzle with System Center 2012 SP1