In the first article in this series, I’ve introduced skybow and our mission. In the next few articles, I’ll explain how we are doing it. In this article I will speak about data modeling and data processing.
1 – What is skybow?
2 – skybow solution accelerators: data modeling and processing
3 – skybow solution accelerators: UI and reporting
4 – skybow solution accelerators: what is under the hood?
5 – skybow: the next generation of products, and my role in it
When skybow solution accelerators are deployed and activated, a standard set of timer jobs, event receivers, business logic and UI elements is deployed on the target scope. Those accelerators help you in three following fields: data modelling (modelling, aggregation and validation), data processing and actions, and UI and reporting.
Data structuring in SharePoint doesn’t work behind the lookup fields. There is no fine data structuring, or master – slave, or master – multiple slaves relations, and intelligent data filtering, aggregation and data validation based on those relations. Nada. You have lists, and lookups between lists – only inside a single SPWeb, that is – and that’s all. What skybow adds are so called “case files”, where it is possible to model data on the more granular ways. Master-slave relations, behaviors and validations based on those relations, properly handling actions during and after data updates, working with dynamic and truly powerful calculated and default values, running totals and aggregations across multiple connected lists from multiple sites, is offered out of the box. The best is: skybow doesn’t mess with your data, doesn’t leave dirt, and doesn’t include 3rd party systems. Everything is left in SharePoint, and all the customizations are stored in schema.xml, easy to understand, migrate and manipulate.
Actions and stages (data processing)
Once you structure and model your data, you need to do some processing with that. With skybow, you will work with actions, stages and expressions.
We differ between three different types of actions: link actions (manual actions), conditional actions, and scheduled actions. Link actions are triggered manually, by clicking on a link or a button. Set of actions which can be performed is already exhaustive: you can execute a get request on URL, start a workflow, add, update or delete a list item, send an email, create a document… If this all is not enough, you can call a web service, execute a PowerShell script, or even call a method from a DLL (which previously has to be registered in GAC).
Expressions in those actions are based on C# syntax, but with placeholders. Placeholder can be any environmental information from SharePoint such as field values, or event receiver properties, etc. So it is totally possible to update a date field value to =[[TripStart]].AddDays([[TripDuratiion]]) You see the mixture of C# and SharePoint field values here – this expression will add the value of “TripDuration” field to the “TripStart” field value, and assign it to the desired field. You can use information and field from the list that the action is attached to, or from any other connected list (connected through lookup fields that is). In this case, this was a fairly simple expression, but they can get much more complex. For that purposes, there is an expression builder that helps you create it. Or you can copy the whole code blocks from the Visual Studio, that is fully legitimate.
Besides link actions, there are also conditional actions, and scheduled actions. Conditional actions are clear – if something happens somewhere with your SharePoint data, the abovementioned actions types can be executed. So you can send that nicely formatted email, with arbitrary attachment from the document library, to the predefined or on-the fly calculated recipients, when the value of a fields changes. The same is true with scheduled actions – you can run your PowerShell script every Wednesday on 9 o’clock. That sort of things.
By combining those three actions, and expressions which can be used with the actions, you are getting a powerful clockworks of background processing tools, which helps you to build a really powerful solution. Based on the conditions mentioned above, you get something we call “stages”. You can create decent approval processes and similar staff with that, both based on conditions (state flows) or actions, and it will work just nice. We don’t call it workflows, since it is not meant to be fully featured BPM solution, we don’t have workflow engine, nor things like branching or parallel process flow, but it is also not to be underestimated: most common process requirements will be met with skybow stages.
A legitimate question at this point is how do we manage to preserve the data integrity. SharePoint receivers won’t always fire, if totals are running across multiple connected lists, how do we assure that they are properly recalculated on one list, even if a field value changes in a lookup-to-another-lookup list? There is a concept of impacts which we introduced, which stores all those relations and artifacts which can impact each other (hence the name…), and “impact processor” which makes sure that everything is where it belongs, and that all the calculations are done properly. It executes asynchronously, so there is no visible delay for the end users: those fine mechanics happen in background. Again, this is done with SharePoint tools – with combination of event receivers and timer jobs, so there is no third party code involved.