The eGenerator converts the TAM specification to serialized objects store into F989998 and F989999 tables (Central Objects tables).
JDE HTML Server make use of these tables records and interprete to the great JDE applications on web.
According to the advice published on JDE Knowledge Garden, the best practice for running a full web serialized objects, we should empty these 2 tables before start to generate the full serilized objects. By doing so, the eGenerator process can be optimize.
A successful full serialized objects generation can easily take more than an hour. Therefore, you need to plan for the downtime. If your business aren't require online 24*7, probably you will do it on weekends or midnights. What if your business can't afford for the downtime, you might ask, any alternative resolutions?
I have came across these 2 alternative resolutions, I think there are good to have options and should be setup and tested long before production go-live, this could save you a lot of time and effort in the future.
1. Create a new environment for the purpose of eGenerator used only.
2. Create a user profile for the purpose of eGenerator used only.
You need to setup a new database data source and change the OCM mapping for the 2 tables.The new database data source is configured with new schema/owner, where it used to store the F989998 and F989999.
Either 1 or 2, you still can't get away the downtime, but this can be minimize to less than 10 minutes.
At the eGenerator client, make sure jdbj.ini is configured to used OCM instead of the spec datasource.
Once ready, you can start the full web serialized objects generation at any time, either sign-on to the dedicated environment, or dedicated user profile.
At last, backup the existing tables, empty these tables, and copy the generated serialized objects tables and overwrite them. To save your time, you can write a stored procedure or script to automate these steps.
These resolutions have been used in production in my past working places, however, you should test it in the development environment to find out the result, justify and decide yourself if you want to implement it in your working place.
JDE HTML Server make use of these tables records and interprete to the great JDE applications on web.
According to the advice published on JDE Knowledge Garden, the best practice for running a full web serialized objects, we should empty these 2 tables before start to generate the full serilized objects. By doing so, the eGenerator process can be optimize.
A successful full serialized objects generation can easily take more than an hour. Therefore, you need to plan for the downtime. If your business aren't require online 24*7, probably you will do it on weekends or midnights. What if your business can't afford for the downtime, you might ask, any alternative resolutions?
I have came across these 2 alternative resolutions, I think there are good to have options and should be setup and tested long before production go-live, this could save you a lot of time and effort in the future.
1. Create a new environment for the purpose of eGenerator used only.
2. Create a user profile for the purpose of eGenerator used only.
You need to setup a new database data source and change the OCM mapping for the 2 tables.The new database data source is configured with new schema/owner, where it used to store the F989998 and F989999.
Either 1 or 2, you still can't get away the downtime, but this can be minimize to less than 10 minutes.
At the eGenerator client, make sure jdbj.ini is configured to used OCM instead of the spec datasource.
Once ready, you can start the full web serialized objects generation at any time, either sign-on to the dedicated environment, or dedicated user profile.
At last, backup the existing tables, empty these tables, and copy the generated serialized objects tables and overwrite them. To save your time, you can write a stored procedure or script to automate these steps.
These resolutions have been used in production in my past working places, however, you should test it in the development environment to find out the result, justify and decide yourself if you want to implement it in your working place.
Can you please Explain the Why the Serialized object table count is decreasing after the every bulk generation. Thanks in Advance.
ReplyDelete