Sharing Objects Accross Projects?

[Former Member]

We are migrating to MII v12.1 and want to setup our projects to be able to leverage common code objects across multiple other projects. The problem we are facing is that query templates require a specific data source. We have multiple sites with common systems deployed and we would like to be able to leverage the same query templates accross all of these sites.

This would not be an issue except that we do all of our development off of a single dev server. Therefore, we have to have distinct data server names for each source system.

I think we need some way of making either the data source in the query template dynamic or be able to some how dynamically set the port in the data server. This may need to go down as a future enhancement request. I just wasn't sure if anyone has come accross this yet.

[jcgood25]

Rob,

Both Michael and Christian suggest some very good programmatic ideas to consider to address your situation. The sticky thread at the top of the forum points to the latest best practice guide, which discusses naming conventions, encourages project and object level consistency and organization (the notion of Common folders and/or Project is mentioned), but your dilemma is a prime example of what makes it difficult to have any particular one size fits all recommendations. Landcapes, data sources, and the application needs come together at times to create the Bermuda triangle of MII design.

We discussed some similar elements as it relates to your project when I visited Thousand Oaks (seems like such a long time ago), and having a single central dev environment does provide another wrinkle to your planning, but you are not alone in this path. You can choose to go with static site based data server names, and then address the runtime elements of this through BLS and applet type parameter overrides in your web pages, but this does add a bit of effort to the overall design and can lead to mistakes or confusion when debugging or testing.

If the application needs support it, I will typically recommend building the templates based upon a data server name that is more indicitive of the data, so if connecting to a LIMS system source that is common to all locations, naming it "LIMS" instead of "SiteA_LIMS" and then build your query templates with this source. For testing purposes and design time, the data server itself on your DEV environment can point to any representative site LIMS database and I recommend keeping the description field for the data server accurate to the current connection since it shows up in the Workbench next to the data server name. Unless you need to have concurrent development on similar but different applications using the same connection this might be a more straightforward approach than doing it programmatically. When you transport this application to TEST and especially PROD (assumedly site based server) the local connection will already be pointing to the proper database and the query templates will simply use "LIMS" as the data server. Virtual Data Servers can also make this quite simple so that the "LIMS" data server on the central DEV box is only a proxy pointer to the site server that really has the database connection.

Regards,

Jeremy

[Former Member]

We usually us an application specific alias for a data server names, e.g. PLANT_KPI and just configure the data source to point to the correct database for that server or installation. This works if the data source is installation specific.

If you really need to manage dynamic db server settings for your templates ( i.e. different data sources or schemas per user or plant in the case of a central server ) we have stored the data source as a user parameter or role, or derive the data source name from the same. And just assign the value at runtime.

Once you get into doing it you will find its not hard to implement, in fact very easy, but it does take time propagating the value throughout your objects.

[Former Member]

Robert,

how about using Global parameters? You can define a global parameter "QueryServer" and set the server name to what is needed in the specific system. In the BLS that runs the query, use query parameter "Server" to set the server with the Global parameter. So you can use the same query with different servers. In an applet you can also set the "Server" parameter.

Michael