Datapolis Guest Expert Presentation: Limitations of SharePoint Designer by Bjoern H. Rapp

Editor's Notes

• #20: The main module of Datapolis Process System is workflow designer. DPS has two additional groups of functionalities. The first one is named Applications. Simply speaking any workflow can be transformed into an application and reused in other workflows. You can also create application in external solution. We can build workflows using applications like Lego bricks. The second group of functions is called Central Administration. Now it’s possible to manage the entire workflow system from one central place.
• #21: This is the graphic designer for a workflow with the green start circle and the red end circle. Here you click on an icon in the tool tray to the left and drag it onto the design board. Creating a state action diagram using the Datapolis process system is a simple matter of drag and drop. Use the state as a virtual pile and the action as a means of moving the item from one pile to another.
• #24: Thanks to applications it will be easier to keep the whole system in order. For example, if you use one procedure in many workflows and the procedure is changed you need to modify all workflows independently. In DPS it is enough to change one application in one place and all workflows will be modified automatically A workflow can be made into an application An Application can run inside a workflow A workflow can access external data through an application
• #25: Depending on where the data is stored, you may create multiple workflows—one for each data storage location. Most of the time a person will kick off an action, but it is possible to set a timer that will wait for a period of time then at a set date and time or after a set interval, the system will launch the next action. We can set the install confirmation timer to go off at the time of the scheduled install requiring the installer to report what happened. After we get Install request workflow finished we can package it as an application. Here the application is represented by an aqua square. We can also package the install confirmation as an application represented by an orange square. We’ll use these application squares later as we embed them in the overall order entry process.
• #26: So after the applications have been created they are accessible as icons in the upper right hand side of the designer window.
• #27: As I mentioned in a previous slide, a workflow application can be reused inside another workflow. This ability permits the workflow designer to control changes and reuse workflows in multiple locations. This simplifies the workflow management process.
• #28: After creating the workflow on the orders list, we will drag and drop the pre-packaged Install request workflow on the pre Install confirmation state. This allows the user to post an install request on the installers calendar, before moving the order to the waiting install state. We will also attach the orange Install confirmation workflow to the Post Install Confirmation state. The Install Confirmation can send data outside SharePoint to the billing system to initiate the invoice.
• #29: In workflow terminology you can define an activity as a detailed process or event that takes place in an action. An action can contain several activities. To define new activities you open a new designer. Activities can do almost anything. They can be placed in containers and executed only under certain conditions or can be executed repeatedly. They can even perform specialized procedures.
• #30: Until now we’ve just been talking about the process designer and the system actions. But the most important parts of a process are the process participants, the people who work with the data to cause things to happen in the real world. Datapolis process system assumes two roles for every new workflow. The author is the person who initiates the workflow, in our case the person who enters the order. By default we have an all users role so that all SharePoint users could do all workflow actions unless we choose otherwise. Sometimes only one person manages items in a given state, but usually several individuals work as a team to fulfill a role. For our process we have a sales team, a customer service team, and an Installer team. I’ve colored the states to match the team in charge of that state. So the Sales team is tan, the customer service team is blue, and the installer is gray. I made the final confirmation state pink to match the manager. Since they each have separate roles, lets define what actions each team can and should perform. Incidentally, this is a slightly different sample workflow.
• #31: Let’s turn focus to how we can monitor the Workflows in DPS. With Datapolis Process System it is possible to see each instance of a running workflow. On this slide I have 11 instances, 11 items. 5 are in the Analyze event state and 5 are in the finished state and one is not showing. Noora has 9 instances in the New LMA state.
• #32: We can look also at the history of each instance and determine exactly when the instance started, what actions were initiated and what activities were performed and when.
• #33: Mention here the clear differences to the lacking monitoring capabilities in SharePoint Designer.
• #34: DPS Management, available from its own page in Central Administration
• #35: From Central Admin, you can drill down to list Datapolis workflows on a per site level.
• #36: Easy to use logging configuration options mapping the Standard SharePoint logging levels for the Windows Event log and the ULS log.
• #37: List summaries and lessons learned…
• #38: List summaries and lessons learned…