Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.

Reusble Models as alternative to Embedded Models

Created: 14 Nov 2012
AnaMan's picture
2 Agree
0 Disagree
+2 2 Votes
Login to vote

A modelling of processes in Symantec Workflow suffers a lot because of very limited structural model decomposition. Because modelling is an analog to programming the most important thing is reusability of a code i.e. ability to define procedures and functions. This idea in Symantec Workflow is fulfilled by decomposition of a project to  submodels. But only separate (main) models as distinct from embedded models can be treated as reusable piece of code. Each embedded model or dialog model is completely independent from others and cannot be used again in other way then by copying it.

Unfortunatelly usability of main models is restricted only to first level of such models. It means that components calling them like Linked Model and Dynamic Linked Model cannot be placed inside embedded or dialog models.
The embedded models are very convenient to organize structure of the model by grouping similar and coherent operations. Such packs of operations are very often repeated in different situations, even in dialog models. Unfortunately they can be only copied. If one even small change is required in a common algorithm all copies must be edited (or replaced by changed one). This is a horrible work.

I propose a new concept of a Reusable Model that would be a mix of main submodel and embedded model.
I imagine that a project tree in Designer can have a separate branch in which a new type of models could be defined. These models could be designed in almost the same way like main models but they should have some same limitations as embedded models (no workflow components or linked models allowed etc.) and from outside thay should see only Properties variables, Global data and variables passed on input. They should return values through output variables. Such models should be possible to call from any level of the main model just like an embedded models are used. So using it will be following: place a component on path required it, choose a model that should called from defined models list (read from project tree), map variables on input and on output and that's all.

When Execution engine meets such component it maps data to input variables and executes selected externally defined model (except that embedded one like Embedded Models do now) and after completion maps output data to calling path variables. Of course a risky problem to solve is a recursion. Nevertheless, even without a recursion the possibility of using the same model (same algorithm) in many places will be a great advantage.

I'm aware that it will possibly require a modifications in execution engines. As I know main models now are processed by engines specific to project type (e.g. Workflow Engine). Models from my concept should be executed by some kind of modified Embedded Model Execution Engine. But I still believe that such functionality could add a really usefull flexibility to workflow projects.