GetConfig[] in IRD

[Steph]

Can GetConfig[] be used in a strategy to retrieve an option from application other than URS?

[mark]

Steph,

Do you mean 'GetConfigOption[]'?
If so, this is from IRD itself:

'The search for the object will start with the properties of the object given by Lookup Sequence (the DN from where the interaction is routed, the T-Server application controlling this DN, the tenant to which they belong, or the Router application). If the option is not found there, the search will continue in the properties of objects corresponding to greater values of Lookup Sequence, in increasing order, until the option is found. The empty string is returned if the option is not found.'

So you can either get the option:value from the DN, T-Server, Tenant or Router.

Mark

[dmonast]

I agree with mark.

But to expand on your question...

You only can retrieve values from the "__ROUTER__" section of the Annex tab for these objects (DN, URS, Tenant, TServer).  You can not retrieve the option values from the any Application's Options tab.

David Monast
Wachovia

[Steph]

Thank you for the answers to my question on GetConfigOption[].
Does it mean that it will take time for URS to get the right value if option is not in DN but in TServer?

[JTL]

No, since you tell it whether to check DNs, TServers etc. It works quite quickly, even in large environments.

It isn't the 'be all and end all' though - sometimes a list object or even an external lookup table offer greater flexibility and more options...

[mark]

That is a good point timetex, in a high volume environment it can be best to get things from an external source, saving URS from doing a lot of processing.

[victor]

Timetex,

very good point. I have done several testings recently, looking at how GetConfigOption[] performs under high-volume calls and compared it to DB-dips. I found dedicated Config Server Proxy to offer the performance I needed without the risk of overloading config server. And did I mention it was MUCH faster than DB-dip and much less resource intensive?

[S]

how does IRD know about getting the values from config proxy as opposed to regular config server? what needs to be taken care of?

[victor]

I guess it is derived from the basic -host -port you set when starting urserver application. So, you would need to set URS to connect to proxy and not to config server.

[JTL]

[quote author=victor link=topic=2447.msg9583#msg9583 date=1191988745]
I guess it is derived from the basic -host -port you set when starting urserver application. So, you would need to set URS to connect to proxy and not to config server.



[/quote]

Aye, spot on. Add a connection to the CSP in the URS connections tab, and use the -host -port for the CSP at startup.

[S]

ok- good point - noted.
How about using the Lists instead of these values in Resources > Annex > __Router__ variables?
do they increase the performance too? or decrease rather? did anyone use list objects and had any problems?

[victor]

What LIST objects

[Fra]

[quote author=s link=topic=2447.msg9628#msg9628 date=1192212908]
ok- good point - noted.
How about using the Lists instead of these values in Resources > Annex > __Router__ variables?
do they increase the performance too? or decrease rather? did anyone use list objects and had any problems?
[/quote]

If you mean IRD lists, I have used sometimes, they are pretty useful when you have the same standard strategy that runs on several RPs; I can't evaluate and compare the performances with Annex ones, but I haven't ever had any problem.

[mark]

[quote author=s link=topic=2447.msg9628#msg9628 date=1192212908]
ok- good point - noted.
How about using the Lists instead of these values in Resources > Annex > __Router__ variables?
do they increase the performance too? or decrease rather? did anyone use list objects and had any problems?
[/quote]

I think in a high volume environment list objects perform better than _ROUTER_ options.

[S]

ya, I do think so.
And moreover, with this LIST we can set access permissions for certain people to see certain Lists only rather than all of them.  
... hmm  ... I am getting new ideas here when responding back...