Resource Registry Use or MisUse Question......

Formally known as "Mercator Inside Integrator 6.7", DataStage TX enables high-volume, complex transactions without the need for additional coding.

Moderators: chulett, rschirm

Post Reply
rep
Participant
Posts: 82
Joined: Tue Jun 19, 2007 8:04 am
Location: New York City

....

Post by rep »

Is everyone sure they don't have an opion on this?

Or anything to say about my mother?
janhess
Participant
Posts: 201
Joined: Thu Sep 18, 2003 2:18 am
Location: UK

Post by janhess »

The benefit of using the resource registry is that you don't have to do map changes for different environments. You just need to set up the initial entries and change the .mrc file.
We use this as much as possible.
rep
Participant
Posts: 82
Joined: Tue Jun 19, 2007 8:04 am
Location: New York City

...

Post by rep »

So, if the directories are the same in each enviroment, and each value in the mrn is exactly the same for each one, would you hardcode that value in the maps, or still put an entry in the mrn?

Like:

Field1 (test) = c:\logs
Field1 (mirror) = c:\logs
Field1 (production) = c:\logs

or just put c:\logs in the map and deploy?

I really appreciate the response!

Thank you!
janhess
Participant
Posts: 201
Joined: Thu Sep 18, 2003 2:18 am
Location: UK

Post by janhess »

Use the resource registry as you may want to change it.
janhess
Participant
Posts: 201
Joined: Thu Sep 18, 2003 2:18 am
Location: UK

Post by janhess »

So what would you do if your ftp destinations were changed for different environments. You would have to change the maps or msl.
By using resource registry you can be confident that the mep you tested can be copied to the live environment with no changes. Only change may be resource registry.

If you document your maps correctly there should be an entry for all the resource variables used.
janhess
Participant
Posts: 201
Joined: Thu Sep 18, 2003 2:18 am
Location: UK

Post by janhess »

Well I supose if you are a consultant you would think that way as it provides you with work every time something changes.
We prefer to have everything soft coded so that we don't have to wory about changing code, only resource registry or properties files.
In our development environment things are constantly changing so this is the least time consuming solution. Things like server paths, JMS queue details, ftp details, http URLs, file names are regularly changed and where we have multiple development environments being accessed from a single event server, we just need to change the .mrc to point to a different environment.
jgibby
Participant
Posts: 42
Joined: Thu Dec 16, 2004 8:48 am

Post by jgibby »

It does seem pointless when all the values are virtually the same for each server. However, if they moved to having those all hard coded and one of the servers had a problem such that they temporarily had to host a directory or two somewhere else or on a different OS (ala Windows), then the need to recode the maps or re-establish the RR system will be a painful lesson to learn.

The real value of the RR is for cross platform compatibility, IMO. In most cases paths will be the same just for uniformity sake. It's just something you're going to have to get used to.

John
"Artificial intelligience is no match for natural stupidity."
jvmerc
Participant
Posts: 94
Joined: Tue Dec 02, 2003 12:57 pm

Post by jvmerc »

I've used a cross between registry, hard coding and paths in an xref file/table.

Some of the problems with the registry are
... if you're using the launcher you have to restart the services after a registry update is made (at least it used t be that way).
... you cannot pass a registry value into another map as anything other than a part of an input or output command. It cannot be used as a data value for a map to perform evaluation on.

One of the nice things about the registry is that its a little more difficulte for the average user/developer to see them. They actually have to know where the registry files are. In our shop theres only a handfull of people that have access to the registry file of whom only three know what the registry file actually is and how to use it of those I think I'm the only one that actually uses it.
rep
Participant
Posts: 82
Joined: Tue Jun 19, 2007 8:04 am
Location: New York City

Post by rep »

jvmerc wrote: I think I'm the only one that actually uses it.
May I ask; do you use RR entries that have the same value for each enviroment, or only for fields that are different between deploytment servers?

As with the other gentlemen who added to the thread, thank you!

Maybe if I were here in it's inception into our systems, and knew all the values from working with them from the go, it wouldn't bother me so much as being new, going to learn an entire system with no documentation or assitance, and having to sort through the mrn for ever other map rule, grabbing 2 - 5 values everytime. It would be that much easier if the values were right there.
jvmerc
Participant
Posts: 94
Joined: Tue Dec 02, 2003 12:57 pm

Post by jvmerc »

Both... but then, for TX our shop is Windows and we run test and prod environments. In theory everything is the same. The differences come in when we test against another environment both internal and external. So, an FTP, for example, would use the same resource name but one would point to the test ftp location, HTTP would work in a similar fashion.

Internally, we have some redundancy in resource names. For example, %host% = \\localmachine\, %domain_po% = \\domain\postoffice\, %domain_poout% = \\domain\postoffice\outbound_data\, %domain_apps% = \\domain\applicationpath\ and so on.

My big problem is that we run DEV, QA and UA on one machine. Using a static registry name doesn't really work well there. So, I use the static name to determine specifics to the mdq files but not the mdq file path.
Though both variable exists.

I really don't like how things are setup here either but seems to work for now. Hard to justify changing a lot.
rep
Participant
Posts: 82
Joined: Tue Jun 19, 2007 8:04 am
Location: New York City

....

Post by rep »

I marked this as a work around, because it was a question about preference, not a direct technical question that can be resloved. I wanted to do this before it slid off into oblivion. If anyone has a strong opinion either way, please PM me, unless posting is still possible.

Thanks to everyone who shared an opinion.
Post Reply