5 Replies Latest reply: May 15, 2014 10:12 AM by Olly Bond RSS

    Two hats - please help...

    Olly Bond

      Hello everyone,

       

      Away from my posts here, I've got a day job at one of Datawatch's European customers, where we run 20 end user Monarch licences, a DataPump server and a Monarch BI server. I've got the lucky job of "looking after" the entire stack - from configuring access rights for the browser-based BI users, to clearing out the job log files from the DataPump server, and making sure that the end users have got enough training to manage what they need to do in Monarch.

       

      We've come a long way in a few years - when I arrived there were two Monarch users - and I know, from conversations here on the forum and from many of you who've emailed me offline, that while your organisation might not have installed the server products from Datawatch, you share some of the same challenges when scaling up Monarch from one desktop to many. How do you make sure that users don't duplicate effort rebuilding the same model? How do you enforce some sort of real audit trail?

       

      When I heard about the user conference, I thought it might be helpful to talk about this experience, so I proposed a topic to Datawatch on "Managing Monarch". I would be really grateful if any of you could share some experiences - either here or by email - which would help me make the presentation relevant to as many of you as possible. I'm very happy to keep any contributions confidential as well.

       

      Now, I'm a big fan, as I'm sure many of you are, of the Dilbert cartoon strip (www.dilbert.com[/url]), featuring the adventures of an intrepid software engineer and his battles with management, personified by his "pointy haired boss". While the pointy haired boss might be interested in "Managing Monarch", Dilbert (and me) would would rather be building models.

       

      To that end, I'm also presenting a talk on "Invisible Data" - which will be an updated (v11) version of the webinar I gave a year or two ago.  This is all about the tricky Report functions (File, ID, Rowno, Recno, Page, Line, Column and Textline) which tend to get skipped over in regular Monarch classes but are really helpful for dealing with difficult data.

       

      I do hope to see you in Vegas,

       

      Best wishes,

       

      Olly

        • Two hats - please help...
          elginreigner _

           

          We've come a long way in a few years - when I arrived there were two Monarch users - and I know, from conversations here on the forum and from many of you who've emailed me offline, that while your organisation might not have installed the server products from Datawatch, you share some of the same challenges when scaling up Monarch from one desktop to many. How do you make sure that users don't duplicate effort rebuilding the same model? How do you enforce some sort of real audit trail?

          /QUOTE

           

          I do not fall into this boat, I am the only modeler here at the moment. Others do occasionally set them up, but I handle all production level models. As for an audit trail, this would depend on how you track your projects. In programming in the past, there is a program called MS Visual Source Safe. This would allow projects to be setup and a user could 'sign out' the project to be worked on. If another user attempted to work on the project it would tell them who has it open, this helped prevent overwriting of code and duplication of effort. I would assume there could be a similar product to help manage Monarch projects.

            • Two hats - please help...
              Olly Bond

              Hi Elgin,

               

              That's a nice idea - checking models and projects out - and that chimes with some other feedback I've heard by email, from users working with shared drives and moving to Sharepoint.

               

              Do you make much use of the linked objects in your models, where you can define a filter or field or function in one model and then import it into another?

               

              Best wishes,

               

              Olly

                • Two hats - please help...
                  elginreigner _

                  I rarely use linked objects only because of complexity and uniqueness of each client's file. The closest I guess would be a generic starting model that can be used across multiple projects. By the time I get done the models are slightly different of each other.

                   

                  I have one user defined function, that is for validating a SSN beyond the built-in functions. Thats basically the extent of my linking.

                    • Two hats - please help...
                      Scott Eshleman

                      I rarely use linked objects only because of complexity and uniqueness of each client's file. The closest I guess would be a generic starting model that can be used across multiple projects. By the time I get done the models are slightly different of each other.

                       

                      I have one user defined function, that is for validating a SSN beyond the built-in functions. Thats basically the extent of my linking.[/QUOTE]

                       

                      Agreed. While I often reuse (import) filters and calculated fields in different scenarios, I rarely consider 'linking' them.

                      I too use the generic starting model concept as a 'library' from which to reference prebuilt filters, calculated fields, etc.

                       

                      In terms of multiple Monarch model builders, I'm more or less the main guy but I often find myself using the same mainframe reports over and over for a multitude of disparate projects.

                      With upward of 300+ mainframe reports available produced daily, I've had to have some organization of the model or models for the reports that I have[/I] written.

                      I've simply referenced the Report Name in the 1st positions of the model's name versus any Dept or Campaign name. For example: R-2030 Maintenance Report[/B]

                      If the model has a specific purpose or uncommon external lookup usage, I will typically include a brief description in the model's name as well.

                        • Two hats - please help...
                          Olly Bond

                          Hello Scott,

                           

                          Nice approach - we also try to stick to SAP transactions as a quick reference to relevant models and reports (LFA1, ADR6, CNS43, CJI8 and customised ones like ZBUDG). I've also imposed on my poor colleagues the indignity of putting their initials as part of the process name on DataPump - so I can see who generates the fewest (and most) errors Getting them to share and re-use objects between each others' models is the next challenge...

                           

                          Best wishes

                           

                          Olly