Best Practice for Global Constants in IRPT files?

[Former Member]

Hi,

For Global constants that need to be accessed inside IRPT files and would only change as the code migrates from Dev->Test-> Production, what is the preferred method of storing and accessing these constants in a reusable way so that we donu2019t have to change the code of individual irpt files. Additionally, this should not be stored in a code file, as the QA team is uncomfortable with changing code files as we migrate through environments.

It seems like just using a constant only .js file would work, but are there other methods and what is the preferred way of configuring global constants/variables?

Thanks for the help.

Kerby

[Former Member]

Hi Kerby,

I was planning on putting all the config values in the database. Then there is no changing of files that are inside the deployment package.

Another idea, particularly if this is not a database app:

What I did for a Portal dynpro app was have multiple properties files named with the host name.

myDevHostName.properties and myQAHostName.properties and myProdHostName.properties.

They all got deployed with the app. The code used the host name to open the appropriate file.

Probably need a custom action block though because I only saw the IP address in the attribute

list and not the server name. And not so good when system names change...

http://<servername>:<portnumber>/XMII/PropertyAccessServlet?mode=List&Content-Type=text/html

--Amy Smith

--Haworth

[Former Member]

Thanks, I think we are going to use Role based properties. They seem to be very good for what we want to do.

One confusing thing though, is that the text role based properties don't play nicely with \ for filepaths. i.e. I put in

and the first time I save the property it reduces to
and then if I save again it goes to \ and then saving a final time shows a blank screen until I delete the property that was being saved.

So I'm just going to have to have more modular properties and have the backslashes in the IRPT's where appropriate.

Thanks for the help.

Kerby

[Former Member]

You can also use Localization objects.

[Former Member]

Often you can use role attributes to do this, Or sometimes set global properties in BLS. Another way is to have an xml file that has name / value pairs which you want to assign. On your start up page, have an xml query (or BLS transaction query) that assigns whatever property values you wish. That way your QA people only have to change the values in an xml file.