<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: FindChart Coding style in Active IQ Unified Manager Discussions</title>
    <link>https://community.netapp.com/t5/Active-IQ-Unified-Manager-Discussions/FindChart-Coding-style/m-p/31580#M6535</link>
    <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Here are my thoughts on the use of multiple FindCharts.&amp;nbsp; I use many FindCharts for my workflows.&amp;nbsp; I actually have a habit of actually splitting my Finders from my Defines.&amp;nbsp; Part of my logic to do this is thinking about reusing FindCharts.&amp;nbsp; It is also easier to make changes in how I want to handle evolving workflow requirements.&amp;nbsp; 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 &amp;gt;10Tb).&amp;nbsp; I actually define the two aggregate FindCharts separately and then user Return Variables to define their uses later on.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;One big FindChart really only makes sense when the Workflow is of very limited scope and might only have one command.&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
    <pubDate>Tue, 24 Jan 2012 23:31:24 GMT</pubDate>
    <dc:creator>goodrum</dc:creator>
    <dc:date>2012-01-24T23:31:24Z</dc:date>
    <item>
      <title>FindChart Coding style</title>
      <link>https://community.netapp.com/t5/Active-IQ-Unified-Manager-Discussions/FindChart-Coding-style/m-p/31575#M6532</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Hi, I would like to ask the experts &lt;SPAN __jive_emoticon_name="happy" __jive_macro_name="emoticon" class="jive_macro jive_emote" src="https://community.netapp.com/5.0.1/images/emoticons/happy.gif"&gt;&lt;/SPAN&gt; on what "coding" style will be better in the long term on Find Chart.. &lt;/P&gt;&lt;P&gt;Let me explain better based on what I saw from WFA in the last few days (and some tests). &lt;/P&gt;&lt;P&gt;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 :&lt;/P&gt;&lt;P&gt;1) delete cloned volume&lt;/P&gt;&lt;P&gt;2) delete sourcefiler snapshot&lt;/P&gt;&lt;P&gt;3) create new snapshot&lt;/P&gt;&lt;P&gt;4) vsm source to destination&lt;/P&gt;&lt;P&gt;5) create volume clone on destination storage from the newly created snapshot&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;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).&lt;/P&gt;&lt;P&gt;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).&lt;/P&gt;&lt;P&gt;the array, source/dest vsm volumes and VSM relation are static defines.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Now the question &lt;SPAN __jive_emoticon_name="happy" __jive_macro_name="emoticon" class="jive_macro jive_emote" src="https://community.netapp.com/5.0.1/images/emoticons/happy.gif"&gt;&lt;/SPAN&gt; &lt;/P&gt;&lt;P&gt;It will be better to create separate FC for every object or to mix definition reducing the number of the FC?&lt;/P&gt;&lt;P&gt;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.&lt;/P&gt;&lt;P&gt;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?&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Thanks&lt;/P&gt;&lt;P&gt;Francesco&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Thu, 05 Jun 2025 06:36:55 GMT</pubDate>
      <guid>https://community.netapp.com/t5/Active-IQ-Unified-Manager-Discussions/FindChart-Coding-style/m-p/31575#M6532</guid>
      <dc:creator>f_duranti</dc:creator>
      <dc:date>2025-06-05T06:36:55Z</dc:date>
    </item>
    <item>
      <title>Re: FindChart Coding style</title>
      <link>https://community.netapp.com/t5/Active-IQ-Unified-Manager-Discussions/FindChart-Coding-style/m-p/31580#M6535</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Here are my thoughts on the use of multiple FindCharts.&amp;nbsp; I use many FindCharts for my workflows.&amp;nbsp; I actually have a habit of actually splitting my Finders from my Defines.&amp;nbsp; Part of my logic to do this is thinking about reusing FindCharts.&amp;nbsp; It is also easier to make changes in how I want to handle evolving workflow requirements.&amp;nbsp; 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 &amp;gt;10Tb).&amp;nbsp; I actually define the two aggregate FindCharts separately and then user Return Variables to define their uses later on.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;One big FindChart really only makes sense when the Workflow is of very limited scope and might only have one command.&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Tue, 24 Jan 2012 23:31:24 GMT</pubDate>
      <guid>https://community.netapp.com/t5/Active-IQ-Unified-Manager-Discussions/FindChart-Coding-style/m-p/31580#M6535</guid>
      <dc:creator>goodrum</dc:creator>
      <dc:date>2012-01-24T23:31:24Z</dc:date>
    </item>
  </channel>
</rss>

