Subscribe

FindChart Coding style

Hi, I would like to ask the experts on what "coding" style will be better in the long term on Find Chart..

Let me explain better based on what I saw from WFA in the last few days (and some tests).

Let me say I have a simple workflow that work across 2 storage and it will do a refresh on a cloned volume on a secondary storage based on a refresh of a snapshot on the primary :

1) delete cloned volume

2) delete sourcefiler snapshot

3) create new snapshot

4) vsm source to destination

5) create volume clone on destination storage from the newly created snapshot

In this workflow there will be those objects involved: 2 array (source and destination), 3 volume (source vsm, destination vsm and cloned), a vsm relationship and a snapshot (not at this moment in 1.0.2).

Of all this objects one if checked via a "finder" (the cloned volume) so that if it don't exist I'll not try to remove it. The same will be true for the snapshot (I'm doing the table/finders to use them in my environment at this moment).

the array, source/dest vsm volumes and VSM relation are static defines.

Now the question

It will be better to create separate FC for every object or to mix definition reducing the number of the FC?

I would probably go for the first because it will probably be more readable (one FC for one object with a good description) but for example the FC with the VSM could include the 2 volume too and also the array definition but visively it will not be "friendly" in my opinion.

Anyone has suggestion on when to use more than one define/finder for each FC or what's the better strategies also with a vision of what will be with the future releases?

Thanks

Francesco

Re: FindChart Coding style

Here are my thoughts on the use of multiple FindCharts.  I use many FindCharts for my workflows.  I actually have a habit of actually splitting my Finders from my Defines.  Part of my logic to do this is thinking about reusing FindCharts.  It is also easier to make changes in how I want to handle evolving workflow requirements.  For example, I have a workflow that will split a set of volumes across multiple aggregates depending on the total size of the new storage requirements (example >10Tb).  I actually define the two aggregate FindCharts separately and then user Return Variables to define their uses later on.

One big FindChart really only makes sense when the Workflow is of very limited scope and might only have one command.