Aside from Monarch’s core functionality as a report mining tool for rapidly performing extraction, loading and transformation (ETL) tasks, its other primary advantage is the reusability of the model and project files that we create so that Monarch can handle just about any data source that we throw its way. But have you used existing models to make the process of building new models even more efficient than building a Monarch model is normally?

We’ve covered a lot of ground so far in the 30 Days to Become a Better Monarch Modeler series, and today we’ll look at how we can repurpose almost all of our hard work. OK, you and I know that it’s not always hard. I won’t tell if you won’t.

On day 18 we’ll review Monarch’s ability to import the objects that have been defined in existing models into a new model.

Read the tutorial

Right off the top I’ll confess that this won’t be a detailed, “how-to” post, as much of what you need to know has not only already been written, but you already have it in your possession if you have Monarch installed on your system.

And since the “Linked Objects Tutorial” is a well written and comprehensive piece, my job here is to reinforce the importance of how importing models objects will make you a better Monarch modeler.

The ability to link to model objects has been available to Monarch Pro users (good point: if you are considering purchasing Monarch and believe that the slightly less costly Standard edition will be enough – or have the Standard edition now then do yourself a huge favor and get the Pro edition as you’ll be giving up far too many genuinely useful features and benefits without it) since v9, but I must take a moment to speculate a little here.

In the two years plus since v9 was released, I can barely recall more than a handful of questions being asked about linking and importing objects on the Monarch forum, and I don’t recall ever having been contacted about the feature outside of the forum. Maybe that’s because everyone has read and understood implicitly the Linked Objects Tutorial, but as much as I’d like to think that’s the case, I don’t buy it. At 85 pages in length, there are plenty of possibilities for confusing new users.

Accordingly, I’m left to suspect that many Monarch modelers are either ignoring the ability, not seeing the usefulness, or perhaps are somewhat intimidated by the terminology and choose not to pursue it further.

And that would be a shame, because if that’s the case, then people (you?) are duplicating effort without reason. Remember, at every opportunity Monarch is all about not duplicating effort. Not rekeying. Not printing. Not bursting. Not highlighting. Not performing technical gymnastics with Excel to do what is easily done in Monarch. Not learning SQL or ADO or Jet or DAO or RDO or .Net or Java or Delphi. And now, not building the same Monarch model objects over and over again.

It’s not that it isn’t fun to work with Monarch, because it is, but there’s a better way.

Reusable Monarch Objects

OK, so what can we bring into our new model from an existing model? Darn near everything that we build for a model, from the basic elements to advanced functionality:

• Templates
• Fields
• Filters
• Calculated fields, including runtime parameters and formula based fields
• External lookups
• Sorts
• Summaries
• Address blocks, and
• User-defined functions

Let’s say that we have a filter that we created in a model to isolate specific department or store numbers in a geographic manner. We created that model for a sales report, but now we’re working on an inventory report. Rather than duplicate the effort required to specify the 50 store numbers in a new filter, we simply and quickly bring that entire filter in as is from the sales report model, and we’re done.

We can go one step further too. Instead of merely importing the filter, and specifying that we will not link to the original filter definition, we can set it up so that if the filter in the sales model ever changes then those changes will be automatically incorporated into the inventory model. We wouldn’t need to revise the inventory one bit for the filter to reflect the new criteria. See the Linked Objects Tutorial for details.

If you’ve created a number of models for the reports that you use regularly, there’s a good chance that you’ve duplicated some effort along the way. If you didn’t already know, with newer versions of Monarch we can jump right to the Table window without having a data source of any kind open. This means that we can build filters and other Table window objects that aren’t dependant on Report window elements such as fields defined in extraction templates and save that model for later use.

I can hear you asking “What good is a model that’s not really built to be a model?”

Monarch Teamwork

Fair enough. What if you built the model with the full intention to importing objects that it defines into the models that you’ll create later? Think of this model not as a model, but instead as a repository or a library of Monarch objects.

Treating a single model file as a repository offers a few advantages:

• Since Monarch doesn’t care how much you build into a model, you can pack a single file with all kinds of stuff
• The more you add, the more that becomes available for other objects
• If you only have one file to maintain and import from, you probably won’t waste time searching all over the place for it

You could place this model in a folder named something like “Monarch Library” and name the model “Shared Monarch Objects.xmod”. Then you’d have created an easy to access and utilize resource for yourself. Or you could do what you learned in kindergarten, and share with your friends.

You’ve become the star Monarch modeler in your group, and if you have others who are still learning the Monarch ropes, you could place your invaluable resource in a shared network folder, or even a SharePoint site. Now take a few moments to teach the new users how to import or link to your objects, and your sharing of your work can enable common methods and tools; in fact standards of a sort.

Would sharing your library with your group add some efficiency and create some savings relating to the cost of developing your processes and solutions?

Have I convinced you to read the Linked Objects Tutorial yet?

Your Task for Today

You know what’s coming, I’m sure. Read the Tutorial. Experiment with importing different objects from existing models into a new model. Do you know how to use “substitutions”?

If you’re confused or unsure of anything relating to reusing model objects or anything discussed previously in the 30 Days to Become a Better Monarch Modeler, ask away by adding a comment below.

Build Sustainable Solutions with Monarch

Models can be built to not just overcome the current challenge, but with a little planning, they can be used to even greater advantage in future models, or to minimize the effort required for building a collection of models in the short term.

Importing and linking your model objects might be the one opportunity that it’s not only acceptable but indeed highly encouraged to plagiarize from your own work or someone else’s and simultaneously excel with Monarch.

—

Continue your commitment to Become a Better Monarch Modeler with Part 19 of the series, or review Part 17.