Screencast Script – Issues with full egen 8.12/8.97

We recently ran into a major issue while building/deploying a full package for one of our clients which runs EnterpriseOne 8.12/Tools Release 8.97. This particular client requests that we perform a manual full egen after deploying full packages. Technically in 8.12 this is not necessary as serialized objects are generated during the package build, but they had experienced some issues with this in the past. To ensure that the issues don’t occur again, we perform a manual full generation of the serialized objects after deploying each full package. In this case, everything went smoothly with the build and deploy. Logging was enabled during the egen and there were no errors present in the genstatus.log or generror.log. Also, surface testing including submitting a batch job yielded no errors. However when users began logging into the system the next day, they began experiencing multiple issues including long load times, hung applications, and eventually batch jobs would no longer run. After some investigation, it was discovered that the serialized objects tables, which would normally have hundreds of thousands of records each, only had a few thousand! This was creating an enormous strain on the network as every application a user loaded had to be generated on the fly.

To correct this issue, we ended up having to perform another full egen after truncating the F989998 and F989999 tables. Once the egen was complete and prior to testing, we backed up the tables just in case they got wiped out again. This ended up being a good move, as immediately after logging in to test from one of the web servers, we checked the record count in the serialized objects tables to discover that they only had a few entries in them again. It is believed that this issue was caused by the spec on demand feature.

To counter this issue, we now bounce services on each of the web servers after completing the full egen AND PRIOR TO logging in to test. We also truncate the serialized objects tables prior to each egen and verify the record count after we log in to test. Since we began employing these methods, we have not encountered this issue again.