Using Alternate EnterpriseOne Serialized Objects Tables

No downtime, middle of the day full serialized objects generation.

When CNC admins have time to sleep they dream of getting more sleep. They imagine that there is the possibility of performing administrative tasks at some time of the day other than during The Maintenance Window.

Generating a full set of serialized objects is not as critical as it was prior to Dynamic Web Generation and Auto Package Discovery, both introduced in the 8.96/8.12 release, but if you are on a Tools Release prior to 8.96 or simply wish to generate a full set of serialized objects without disrupting your users or possibly your social life, try using two sets of the serialized objects tables (F989998/F989999).

The concept is that *PUBLIC will be using one set of serialized objects tables while an EGEN user will be using another set during the full generation.

Setup

Create an E1 user EGEN with associated security record, role membership, etc. Ensure the EGEN user has access to the J* environments.

Using OMW, generate the F989998 and F989999 serialized objects tables in the Business Data datasource for each environment.

Create copies of System OCM's for F989998 and F989999 for all J* environments so that you have OCM's for both tables for both Central Objects and Business Data for both *PUBLIC and EGEN, one active and one inactive.

The easiest way to get the OCM's copied correctly is to copy the existing F989998 and F989999 OCM for Central Objects, changing the Data Source to Business Data and the System Role to EGEN during the copy and then make those OCM's active. Then copy all J* environment F989998/F989999 OCM's, changing only the System Role from *PUBLIC to EGEN or from EGEN to *PUBLIC during the copy. This step will create the proper inactive OCM's.

You should end up with something that looks like this:

Environment	Object Name	Object Type	Primary Data Source	System Role	Object Status
JDV812	F989998	TBLE	Central Objects - DV812	EGEN	NA
JDV812	F989998	TBLE	Business Data - TEST	*PUBLIC	NA
JDV812	F989998	TBLE	Business Data - TEST	EGEN	AV
JDV812	F989998	TBLE	Central Objects - DV812	*PUBLIC	AV
JDV812	F989999	TBLE	Business Data - TEST	EGEN	AV
JDV812	F989999	TBLE	Central Objects - DV812	*PUBLIC	AV
JDV812	F989999	TBLE	Central Objects - DV812	EGEN	NA
JDV812	F989999	TBLE	Business Data - TEST	*PUBLIC	NA
JPD812	F989998	TBLE	Central Objects - PD812	EGEN	NA
JPD812	F989998	TBLE	Central Objects - PD812	*PUBLIC	AV
JPD812	F989998	TBLE	Business Data - PROD	EGEN	AV
JPD812	F989998	TBLE	Business Data - PROD	*PUBLIC	NA
JPD812	F989999	TBLE	Business Data - PROD	EGEN	AV
JPD812	F989999	TBLE	Central Objects - PD812	*PUBLIC	AV
JPD812	F989999	TBLE	Business Data - PROD	*PUBLIC	NA
JPD812	F989999	TBLE	Central Objects - PD812	EGEN	NA
JPY812	F989998	TBLE	Central Objects - PY812	EGEN	NA
JPY812	F989998	TBLE	Central Objects - PY812	*PUBLIC	AV
JPY812	F989998	TBLE	Business Data - CRP	*PUBLIC	NA
JPY812	F989998	TBLE	Business Data - CRP	EGEN	AV
JPY812	F989999	TBLE	Business Data - CRP	EGEN	AV
JPY812	F989999	TBLE	Central Objects - PY812	*PUBLIC	AV
JPY812	F989999	TBLE	Central Objects - PY812	EGEN	NA
JPY812	F989999	TBLE	Business Data - CRP	*PUBLIC	NA

Again, the concept is that *PUBLIC will be using one set of serialized objects tables while EGEN will be using another set during the generation. When the full gen is done, you will have a completely populated set of serialized objects tables waiting to be used while the other set continued to be used during the full generation. An OCM swap and a cache flush will put the newly generated tables into use without interrupting users.

Execution

Update (10/25/2009):  Starting with release 8.12 you must generate a package manifest for auto-package discovery to work when you deploy update (or full) packages.  This package manifest exists as a record in the serialized objects tables so if you truncate the F989998/9 tables prior to a full generation, the auto-package discovery functionality will be broken.  Since this impacts our method I have added a step to account for this functionality.

Steps for 8.12/8.96 and greater:

1. Truncate the serialized tables that are actively OCM mapped to the EGEN E1 user
2. Comment out the [JDBJ-SPEC DATA SOURCE] stanza in jdbj.ini to use the WebDev machine for egeneration (Thanks to John Bassett for this tip.)
3. Log into egenerator using the EGEN E1 user
4. Generate manifest
   
5. Generate core objects
6. Login to the web client once using the EGEN E1 user
7. If you wish to pre-generate serialized objects, perform a full generation
8. Rebuild the indexes for the F989998 and F989999 tables
9. Perform an OCM swap for *PUBLIC and EGEN
10. Flush the OCM and serialized objects caches

Steps prior to 8.12/8.96:

1. Truncate the serialized tables that are actively OCM mapped to the EGEN E1 user
2. Comment out the [JDBJ-SPEC DATA SOURCE] stanza in jdbj.ini to use the WebDev machine for egeneration (Thanks to John Bassett for this tip.)
3. Log into egenerator using the EGEN E1 user
4. Generate core objects
5. Login to the web client once using the EGEN E1 user
6. If you wish to pre-generate a full set of serialized objects, perform a full generation
7. Rebuild the indexes for the F989998 and F989999 tables
8. Perform an OCM swap for *PUBLIC and EGEN
9. Flush the OCM and serialized objects caches

The OCM swap will make the "alternate" serialized objects tables active for *PUBLIC and inactive for EGEN and will make the "original" serialized objects tables inactive for *PUBLIC and active for EGEN, ready for the next full gen and swap.

Example

Before:

Environment	Object Name	Object Type	Primary Data Source	System Role	Object Status
JDV812	F989998	TBLE	Central Objects - DV812	EGEN	NA
JDV812	F989998	TBLE	Business Data - TEST	*PUBLIC	NA
JDV812	F989998	TBLE	Business Data - TEST	EGEN	AV
JDV812	F989998	TBLE	Central Objects - DV812	*PUBLIC	AV
JDV812	F989999	TBLE	Business Data - TEST	EGEN	AV
JDV812	F989999	TBLE	Central Objects - DV812	*PUBLIC	AV
JDV812	F989999	TBLE	Central Objects - DV812	EGEN	NA
JDV812	F989999	TBLE	Business Data - TEST	*PUBLIC	NA

After:

Environment	Object Name	Object Type	Primary Data Source	System Role	Object Status
JDV812	F989998	TBLE	Central Objects - DV812	EGEN	AV
JDV812	F989998	TBLE	Business Data - TEST	*PUBLIC	AV
JDV812	F989998	TBLE	Business Data - TEST	EGEN	NA
JDV812	F989998	TBLE	Central Objects - DV812	*PUBLIC	NA
JDV812	F989999	TBLE	Business Data - TEST	EGEN	NA
JDV812	F989999	TBLE	Central Objects - DV812	*PUBLIC	NA
JDV812	F989999	TBLE	Central Objects - DV812	EGEN	AV
JDV812	F989999	TBLE	Business Data - TEST	*PUBLIC	AV

Now go dream about getting more sleep.

Change Integrated Solutions (WebSphere) Console Timeout

In IBM's Integrated Solutions Console (formerly known as WebSphere Console), the administrative interface for WebSphere 6.1, the default console user inactivity timeout is 30 minutes. I happen to think this is a bit short, particularly since most anyone using the console is a highly trusted user, generally an IT administrator who is well-versed in computer and network security practices.

For this reason, and since I find it such a hassle to come back to the console after a short time and be told that "Your session has become invalid", I change the timeout to something I think is more reasonable, like 720 minutes.

Please note that I am referring to the timeout for the admin console, not session timeouts.

If you are using WebSphere Network Deployment (and you should be) edit this attribute in the following file on the Network Deployment machine:

C:\Program Files\IBM\WebSphere\AppServer\profiles\Dmgr01\config\cells\NetworkDeploymentservernameCell01\applications\isclite.ear\deployments\isclite\deployment.xml

Set the attribute invalidationTimeout to the desired value, in minutes, where the maximum value is -1 (do not time out)


Restart the WebSphere service on the Network Deployment machine.


If you are not using Network Deployment.....you should be, so go implement ND and follow the directions above.


If you are still on WebSphere 6 (and maybe 5):

Edit the ${WAS_HOME}/systemApps/adminconsole.ear/deployment.xml file to change the invalidationTimeout attribute value to the desired session timeout. The default is 30.

Restart the application service.

Auto Restart WebSphere Application Servers

So you've installed the EnterpriseOne HTML application on your fancy WebSphere Application Server (uppercase) and you are doing some restart/reboot testing. If you are using WebSphere Network Deployment, as you absolutely should be, you may notice that if you reboot the entire box, the previously running application servers (lowercase) do not restart even though the node agent service is set to automatically start.

This is because a setting in the WebSphere Integrated Solutions Console (fka Network Deployment Console) and not the node agent service startup setting controls the startup state of the application servers.

The restart state behavior of the application servers is determined by what IBM calls the Monitoring Policy settings. These settings tell the node agent what it should do with the java processes after both an internal (to WebSphere) abnormal shutdown and a complete node restart.

The settings we are concerned with are Automatic restart and Node restart state. The first controls how WebSphere will react to an internal application server failure and the default is set to True. The second is how WebSphere will handle a complete node start (reboot) and the default is set to Stopped. This means that if you restart the physical box (or it reboots itself) you will have to manually start the application servers or WebSphere cluster of application servers in the WebSphere Integrated Solutions Console.

My philosophy on automatic starts is that it should be disallowed only in situations where automatically restarting will either undoubtedly fail (ex: failing back an E1 enterprise server on a W2K3 cluster) or could cause corruption. Since WebSphere is mostly at the presentation layer and since Oracle is making extensive progress with Failed Transaction Recovery, I prefer that the application servers start automatically on node restart.

To have the application servers automatically restart, set the Node restart state to RUNNING in the Servers> Application Servers> server_name > Server Infrastructure > Java and Process Management > Monitoring Policy section of the WebSphere Integrated Solutions Console. Click OK, save your changes, and test.