Build better local testing/debugging tools for SMA Workflows
It's very difficult to get a local machine set up so that Workflows destined for SMA can be tested and debugged on a local machine as though they were in the SMA environment. A lot of times you have to write a workflow on your local machine, put it in SMA, watch it break (often without much debugging output unless you used write-verbose), and then you have to try to fix it on your local machine. And your local machine doesn't match SMA, so you have to upload it to SMA again to test, watch if fail, and cycle repeats. I know there are ways to get the machine to more closely match SMA by installing certain modules, but it's confusing and trips up a lot of users.
SMA ISE Add-on which allows you to test and debug runbooks from ISE has been released.
Check this blog post for more details – blogs.technet.microsoft.com/orchestrator/20..
Trond Hindenes commented
I don't understand why MS is encouraging the use of the WAP portal for authoring. We already have two IDE's (ISE and Visual Studio), both are vastly better than the editing experience in the wap portal. I'm getting the feeling that MS doesn't understand the real use cases for SMA / Automation and their complexities.
For me it's two folds:
Being able to debug the workflow on the fly is a must. Either through ISE or the portal is not that important, as long as the tool set is rich. Like inspecting variable content during runtime and the likes. For now that means ISE for me. Though where the ISE is lacking is in simulating usage of SMA assets (would like too steer away from any changes in code between where I debug and where the code normally runs) . As assets are a big part of SMA workflow utilization, this becomes quite important, especially from a code quality standpoint. Keeping code static as one moves between environments (Test, QA, Prod), where only the content of the assets change (not the asset name the code fetches based on), would help keep potential of introducing errors low.
Also in a multi-tier SMA environment (like multiple isolated AD domains), code reuse and standardization helps with the formidable code maintenance job. If the assets could have more metadata added to them, one could maybe manage all assets in a central SMA install, and have logic that syncs them out to the correct headless SMA installations based on configurable asset metadata. Though this would mean that one would have to be able to have multiple assets of the same type with the same variable names, but maybe be able to group them in a way to allow this name duplication (like Test, QA, Prod).
Also the resource usage of installing the WAP portal does not always make sense for all SMA installs. So in these situations having something else that can connect to SMA DB would be a big help (either it's the ISE or maybe Visual Studio).
There has been done some great work around the community with integrating workflow code into TFS, getting assets into TFS would also be nice. One place to manage all.
Especially if we are going the way of increased nested workflows, debugging functionality and best practices must evolve hand in hand. Robust coding patterns for error / debugging should become a priority if you ask me.