KINI access during Init

I've been told in the past that I simply cannot access the KINI table during Init, because there is no prgCtx yet. A while ago I had thought I had a solution by grabbing the DB wizapi and calling .GetPrgCtx on that, and it worked great, except it turned out it causes problems during a database upgrade.

So in CS10 and up, is there any approved method for gaining access to the KINI table during init? I'm talking about an individual object's __Init method. For a long time now I've had some features that depend on a configuration option of some sort that needs to be set during the __Init method, because I set a certain subtype list or child type list or whatever that needs to be known when that object is registering with its subsystem. And for quite a while I had a solution that worked--I stored my configration in .ini files. But more recently I decided to move those configuration options into the KINI table so that I didn't have to keep .ini files on 5 or 10 different OTCS servers synchronized. And it works great for most options, but not the ones that I need access to during __Init.

And so I ask if there's a supported way to gain access to KINI during __Init.

Find more posts tagged with

Comments

Brett_Conley

I have a hunch this won't be smiled upon, either, but tell me if this sounds like it would work:

First, in my module's Root.Startup method, I obtain a prgCtx from the DB wizapi, then init all objects, then delete the wizapi object and prgCtx afterwards. The code would look like this:

Object dbwas = $DBWizApi.DBWizApiSubsystemObject wizapi = dbwas.SetUpWizData()Assoc prgAssoc = wizapi.GetPrgCtx()if(prgAssoc.OK)	$MyModule.fPrgCtx = prgAssoc.PrgCtxend// Any __Init methods in need of a KINI value can use $MyModule.fPrgCtx to get it.$Kernel.OSpaceUtils.InitObjects( globals.f__InitObjs )OS.Delete(wizapi)$MyModule.fPrgCtx.Delete()$MyModule.fPrgCtx = undefined

Chris Meyer

Hi Brett, I'm wondering what need you have for a prgCtx at startup? You have to consider that a prgCtx cannot be allocated if Content Server doesn't have a database attached. This will be a problem if the database is disconnected (e.g., during system maintenance) and the service gets restarted. Due to this problem I no longer make any __Init() calls dependent on a prgCtx object.

On 7 February 2014 19:03, eLink Entry: Content Server IDE Development Forum <contentserver-ide@elinkkc.opentext.com> wrote:

KINI access during Init Posted bybrettc@infograph.com (Conley, Brett)On 02-07-2014 13:00

I have a hunch this won't be smiled upon, either, but tell me if this sounds like it would work: First, in my module's Root.Startup method, I obtain a prgCtx from the DB wizapi, then init all objects, then delete the wizapi object and prgCtx afterwards. The code would look like this:Object dbwas = $DBWizApi.DBWizApiSubsystemObject wizapi = dbwas.SetUpWizData()Assoc prgAssoc = wizapi.GetPrgCtx()if(prgAssoc.OK) $MyModule.fPrgCtx = prgAssoc.PrgCtxend// Any __Init methods in need of a KINI value can use $MyModule.fPrgCtx to get it.$Kernel.OSpaceUtils.InitObjects( globals.f__InitObjs )OS.Delete(wizapi)$MyModule.fPrgCtx.Delete()$MyModule.fPrgCtx = undefined
[To post a comment, use the normal reply function]
Topic: KINI access during Init
Forum: Content Server IDE Development Forum
Content Server: Knowledge Center

http://schwiiz.org/?cat=17

Brett_Conley

Fair question. I'll give you a couple examples. Our software allows annotations to be created and associated with the documents they belong to. Some customers want to be able to download these annotation files and move them to other systems, but in general this is not something we want everyone to do (get at the raw files).

So, to accomplish this configuration option, my annotation webnode object's _SubclassInit method (called by __Init) adds {'download'} to (or removes it from) the .fCmdNames of the object, so that download is available only if configured. This is something that could be accomplished by overriding a few other objects in oscript, but is much more straightforward to nip it at startup.

Another example: we also allow users to associate one doc with another (typically used for CAD xrefs). The association is accomplished by adding the ref doc as a child of the doc it is to be associated with. Normally, document objects cannot contain children. And while you might argue with the wisdom of the design, it is one I inherited and now can not do much more than maintain it. But many customers that use CAD also use the CADManager module, which has its own method of associating xrefs, so our method is not needed.

So to accomplish this, in an __Init method, the document object's .fChildSubtypes member is modified by adding a 144 to its list, depending on a configuration value. And that configuration value, and the one for the download annotation mentioned above, are stored in the KINI table.

I'm not too worried about failures if the DB happens to be disconnected. It will gracefully fail to make the assignment defined in KINI, and it won't matter because nobody will be using the system during that time.

Chris Meyer

Hi Brett, as long as you always consider that a prgCtx might not be available then you should be safe.

As a side topic, there are two other approaches you might consider. First, the _SubclassIsEnabled() function on WebNodeCMD is used to enable or disable a function menu at runtime. You could use this to control whether the download link should be visible.

Second, you could also move your configuration settings into the opentext.ini and make it independent of the database. It's not as easy to maintain in a cluster environment, but it is an option.

I've seen other instances where standard child-parent relationships were changed. It's quite easy to do without having to modify anything in code: The enforcement of parent-child relationships in Content Server is only enforced by the user interface. With a URL manipulation (i.e., changing the parentId URL parameter on the create page) you can add most subtypes to any other subtype. Even with LAPI you can move a folder under a document. I'm not sure what side-effects this has, so it's probably not recommended. Cheers.

---

My Content Server Dev Blog: http://schwiiz.org/?cat=17

On 7 February 2014 21:48, eLink Entry: Content Server IDE Development Forum <contentserver-ide@elinkkc.opentext.com> wrote:

Re KINI access during Init Posted bybrettc@infograph.com (Conley, Brett)On 02-07-2014 15:47

Fair question. I'll give you a couple examples. Our software allows annotations to be created and associated with the documents they belong to. Some customers want to be able to download these annotation files and move them to other systems, but in general this is not something we want everyone to do (get at the raw files). So, to accomplish this configuration option, my annotation webnode object's _SubclassInit method (called by __Init) adds {'download'} to (or removes it from) the .fCmdNames of the object, so that download is available only if configured. This is something that could be accomplished by overriding a few other objects in oscript, but is much more straightforward to nip it at startup. Another example: we also allow users to associate one doc with another (typically used for CAD xrefs). The association is accomplished by adding the ref doc as a child of the doc it is to be associated with. Normally, document objects cannot contain children. And while you might argue with the wisdom of the design, it is one I inherited and now can not do much more than maintain it. But many customers that use CAD also use the CADManager module, which has its own method of associating xrefs, so our method is not needed. So to accomplish this, in an __Init method, the document object's .fChildSubtypes member is modified by adding a 144 to its list, depending on a configuration value. And that configuration value, and the one for the download annotation mentioned above, are stored in the KINI table. I'm not too worried about failures if the DB happens to be disconnected. It will gracefully fail to make the assignment defined in KINI, and it won't matter because nobody will be using the system during that time.
[To post a comment, use the normal reply function]
Topic: KINI access during Init
Forum: Content Server IDE Development Forum
Content Server: Knowledge Center

Brett_Conley

We use to store these values in a .ini file, and it's the difficulty of maintaining the values in a cluster environment that caused us to move them into KINI. I'd prefer not to go back if possible.

The original issue is that the method of acquiring a prgCtx at startup while a DB upgrade was being performed was causing a problem with the prgCtx that the DB upgrade process was using--I'm still not quite clear on the how, but it caused the DB upgrade to assign the wrong version values to the different tables in the database.

So I'm not sure this question can be answered effectively by anyone who doesn't see how my original code could cause that kind of a problem. I didn't see any problem with it, and it worked well. It was only after a few customers discovered an error and bringing it to the attention of the top OT developers that the cause was found.

So the main question is: would my sample code pasted above avoid the issue that I've described? The thinking behind it is that if I destroy the prgCtx after using it, the DB upgrade would still have to create its own and hopefully this would force it to obtain the correct version values to assign during the upgrade.