Adding an ospace to existing module - managing the upgrade

HFCDev · 2021-04-30T17:13:44+00:00

There was an error rendering this rich post.

Hi,

This has probably come up a few times, but admittedly it's not frequent. Let's say you have a module with, say, 2 ospaces. Now, in the new version, let's say you add a 3rd. Now you have a module with a higher revision number, so when you drop it in staging, it shows up as upgradeable. If you go through the vanilla process of upgrade, the new ospace will not spin up - why - because it's not in the opentext.ini file. The module's ospaces entry doesn't get updated even if the module's ini shows the new ospace.

Is there an elegant way (something to call in your configure request handler) where you can force opentext.ini to update the manifest of ospaces in your module?

Thanks in advance

-Hugh

Find more posts tagged with

Comments

Nizar Ghazal

It's been a little while since I've had to do this, but I think you'll need to look at OTINIUPG.oll for some examples of this. It should be included in the core ospaces of your OTHOME, and should contain some samples of what we usually do for "upgrading" to include a new OSpace in a module.

As for the implementation of this on your own, unfortunately, I think some OScript is going to need to be written. I don't know of a way that one can just feed parameters to some reqHandler. You'll want to keep an eye on the Vnn scripts in OTINIUPG for examples. If you check out V46, that's where we moved our own webreportswf into webreports core.

The relevant bit of the OScript docs to follow along with: https://knowledge.opentext.com/knowledge/cs.dll/fetch/-15106263/15106294/15106295/16376487/67794710/67790529/documentation/fileprefs.html

Here is a snippet of a sample that I think you'd need to do, if you cannot see V46:

Where fp is your OT.ini path.

Integer status

String ospace

String section = 'Modules'

String prefName = 'ospaces_yourospace'

Dynamic OSpaces

Ospaces = FilePrefs.GetPref( fp, section, prefName )

Ospaces = Str.StringToValue( Ospaces )

if ( Type( Ospaces ) == ListType )

for ospace in Ospaces

if ( ospace == 'the_ospace_you_need_to_add' )

ospaceRefExists = TRUE

break

end

if ( !ospaceRefExists )

Ospaces = {@Ospaces, 'the_ospace_you_need_to_add'}

status = FilePrefs.AddPref( fp, section, prefName, Str.String( Ospaces ) )

...

Hope that helps.

HFCDev

Hi Nizar,

Thanks for this! Actually this does solve at least part of my problem. I assume we can use the same functionality to remove entries from the module ini section for those modules that are now deprecated because their ospace is included. The code block you listed is what adds the webreportswf to the list of ospaces for the WebReports module. So yes, the oscript you sent is definitely useful, but where would I call it from a 3rd party module?

In a module, where would a block of code like that get called from the module configure request handler? It looks like the otiniupg is not loaded normally, meaning your upgrade agent must load it after the fact or something.

-Hugh

Nizar Ghazal

I think what you could do in your custom module is to add/overwrite your existing DoCustomStep() script in the Configure you'd have already from WebAdmin.

Maybe just add a sub-script that'll check for and add the module to the ini?

Will just need to iterate a version number (fVersion) in the module to cause it to want to go through an upgrade step, I believe. :-)

David Henshaw

Hi Hugh.

I don't know you need to do anything "smart" to get the additional OSpaces to register and load.

We had this requirement with one of our products - where we used to provide two additional functions depending via separate modules. The core product registered its OSpaces and then the other modules there's - so you'd see in the opentext.ini a line for each module, with corresponding entry for the ospaces to load.

All I recall we had to do is merge our OSpaces into the core module, and updated the module's INI file to include them in the list of OSpaces to load. This included updating the main OSpace's fOSpaces feature in the orphan of WebModule to include the additional OSpaces.

Our module includes a DoCustomStep - but it isn't doing anything to update INI files or KIni etc. We're simply using that to run script to create a volume on our solution implements.

When customers who were running the older version of the product (which required 3 modules for all features) upgrade, they remove the two supplemental modules first, then run a standard upgrade of the core module. Post that upgrade, the opentext.ini file looks as required with all the OSpaces registered and listed under the core module entry. Our license key then activates features.

Have seen no issues with this so far.

Regards,

David

HFCDev

Hi David,

When we went with a revised 21.1 build that did have a revised module list, on upgrade, it seemed to miss doing anything. In this post, the response that Nizar gave actually was quite useful. We're on a tight timeline for an interim release, so I will probably not fully implement this feature until the next formal release. I am curious how OpenText manages things like in WebReports, I see how they added webreportswf to the list of modules for core webreports, but how did they manage the uninstall of the webreportswf module?

-Hugh

David Henshaw

Hi Hugh,

Dunno of head how uninstalling an existing module can be done programmatically as part of install/upgrade on another. In our case, that part of the process is manual and customers are informed to do the uninstall prior to upgrading our solution. As all our settings and data are stored in KINI, this of course is possible, as there's no data loss - such that when the core solution is upgraded and loads the OSpaces (That were part of the old modules), we pick up where we left off.

Rgds,

David.