Microsoft PowerApps and Flow have been generally available since late 2016. They’re both tools that allow business users to streamline business processes without the use of code. Microsoft positioned PowerApps as their recommended replacement for InfoPath as the business user’s forms designer, and Flow as their replacement for SharePoint Workflow.
While these are welcomed replacements, both solutions also provide a broader level of support to the Microsoft stack and across a wide array of third-party applications. I’ve recently been working with PowerApps and Flow to replace some internal applications, as well as to build proof-of-concepts for our existing clients. Here’s what I think of each, both separately and when putting them together… Read More…
Workflow in SharePoint 2013 has undergone quite the architectural change from its SharePoint 2010 ancestor. I documented many of the major changes in a previous blog post, “What Changed in SharePoint 2013 Workflow? Pretty Much Everything.” While SharePoint 2013 is backwards-compatible with SharePoint 2010 workflows, you may decide that the benefits of the new design are needed. The purpose of this post is to illustrate the new considerations you’ll need to keep in mind when targeting SharePoint 2013 workflows. The SharePoint 2010 project we’ll use for this example is the one from my very first AIS blog post, “Developing Multi-Tiered Solutions for SharePoint.”
Figure 1 - Sample WebAPI methods for Section Document Merge and Post-Merge Actions.
In our example project there are actually two workflows, SectionDocumentApprovalState (SDAS) and MasterDocumentApproval (MDA). The MDA checks if the various SDAS-related sections have been merged and finalized, then notifies specific users for approval of the final document. An instance of SDAS is created for each section, created from the Master Document that monitors the editing and approval of the specific section. We’ll focus on just the SDAS workflow. In the previous post, I referred to the workflows as being part of the Presentation Layer and the custom code called into the Business Layer. Both of these layers will change in a SharePoint 2013 workflow solution.
If you have been following any of the news about SharePoint 2013, you already know that the workflow capability has been enhanced significantly. The most important change is that workflows now execute outside SharePoint. Please refer to the diagram below. (This diagram is taken from MSDN with some annotations.) As you can see, workflows are hosted externally. The external host for workflows can either be Windows Azure or customer-provided infrastructure. Why is this change so important? Recall all the knobs and switches we had to turn as SharePoint developers to prevent workflow execution from overwhelming the SharePoint farm. Read More…
Have you taken a look at the new SharePoint yet?
If you’ve spent any time reading our blog, you know by now that SharePoint 2013 introduces extraordinary new features to change the way you work, share, discover, organize and build sites. And now we’ve put together a quick guide highlighting the top features that may inpact your business.
Download The Top Reasons Why Your Business Will Love the New SharePoint now! (No form required,)
The Top Reasons Why Your Business Will Love the New SharePoint guide provides you with an overview of the latest and greatest that comes with SharePoint 2013, including:
- Smarter Search
- Simpler and Mobile-Ready UI
- SharePoint App Store Model
- Better Workflow
- Social SharePoint…and more, including easy migration tools and lower costs.
Download your copy today!
And if you’re in the DC area, AIS is hosting an “Introduction to SharePoint 2013” event at the Microsoft office in Chevy Chase, MD on March 20th. Click here to learn more and register.
Workflow, as far as I can tell at this point, is one of the most overhauled functionalities from SharePoint 2010 to SharePoint 2013. The first major difference is that it’s no longer contained within SharePoint. Workflow is now handled by Windows Azure Workflow (WAW).
“Whoa, whoa, whoa! Does that mean I’m going to have to pay Microsoft some hefty usage fees to have Workflow in my 2013 environment? I really don’t see how that’s going to fly with the bosses,” you say.
Fortunately, no, that’s not the case. While I’m sure there will be a model for this, it’s not the only one. You can host WAW on-premises just like SharePoint. We’ll delve into that momentarily. Windows Azure Workflow is built on Windows Workflow Foundation 4.5 (WF4.5). WF4.5 introduces several new features as detailed in the MSDN article “What’s New in Windows Workflow Foundation.” This will require a separate install that can run on a SharePoint server or its own environment. We’ll also look at the architectural implications in a bit.
The “meat” of this post is going to focus on three areas: Architecture, Development, and how these would affect the design of an existing SharePoint 2010 Workflow project. The architecture changes only start with WAW and WF4.5. We’ll discuss the installation requirements, how it’s hosted, security, and the Pros and Cons of WAW. The development story has changed, at least to me, far more. I’ll explain the changes to coding (Hint: You can’t…directly), how web services can remedy the last statement, and custom actions. Finally, we’ll take a look at the project I discussed in my last post “Developing Multi-Tiered Solutions in SharePoint” and how that design would be changed for a SharePoint 2013 environment.