In order to bring you the best possible user experience, this site uses Javascript. If you are seeing this message, it is likely that the Javascript option in your browser is disabled. For optimal viewing of this site, please ensure that Javascript is enabled for your browser.
Login  |   On Demand  |   Home  |   qad.com




Additional Customization Topics
Using the wizard to re-create a procedure. Presuming the procedure is not modified, use the wizard to regenerate the procedure that loads that table, in the few instances where existing baseline tables have custom columns added to them.
In considering dim and non-history fact tables that have the new custom columns populated by a post-load update procedure, it is not necessary to update the existing procedure for that dim/non-history fact.
Dealing with custom/modified code. Carefully add the column to all relevant places in the corresponding Custom/Modified procedures if:
In the few instances where existing baseline tables have custom columns added to them, and
the correlating load procedures for that table are either Custom or Modified, and
the new column should be populated by a prior table; for instance history fact tables.
Populating new custom columns in empty perm/fact tables. If custom columns have been added to empty perm or fact tables, the tables have been re-created, and their procedures regenerated, these tables should populate normally as part of the historic load. In some instances, there should be custom tables created to mimic the original historic load for the population of fact tables.
Populating new custom columns in already populated perm. If a new custom column is added to an existing already populated perm table, devise some type of creative update script that can update that perm table for all of the history records it contains; the exception here is the perm_om_invoice_header and perm_om_invoice_line tables, which are currently getting repopulated every day. This is an interesting exercise for the large tr_hist and gltr_hist and their correlating perm tables, especially if the customer has archived some of the data already in those tables.
Once the data is loaded into the perm tables for those columns, it can be fed on up to the fact tables. Depending on the structure of the customization, this can require a full historic reload of that fact, or just a historic reload of that individual column via the custom path. If at all feasible, try to use the latter option. See Historically Reloading Modules.
Populating new custom columns in populated non-history fact table where custom columns were added to tables that come after the perm table; column is in perm table, but not tables after. In the case where the new tables added to a fact existed in the perm table, the ideal first option is to use the new custom path to do a full historic update of the column in question. If that is difficult, option two would be to simply do a historic reload from perm to accomplish this. See Historically Reloading Modules.
Populating new custom columns in populated history fact table where custom columns were added to tables that come after the perm table; column is in perm table, but not tables after. In the case where the new tables added to a history fact existed in the perm table, it is likely that you must perform a historic reload from perm that includes the new custom path staging tables in order to accomplish this. See Historically Reloading Modules.
Cloning load tables to bring in outside data sources (flat files or other databases). If you add data from an outside data source to the data warehouse, the customer must provide a column map of which tables/columns in their outside data source map to which ERP tables and columns. A clone of the existing load tables can be made and mapped to their outside data source. Create a post-load procedure to insert the data from the clone into the existing baseline load tables. The job sequence would then be to:
Truncate the existing load table.
Run the cloned table load process, which should include the post-load procedure that populates the baseline load table once the cloned load is complete.
All the remaining steps should be essentially the same. There may be a requirement to reload all data in the fact for that given source if the source system for the outside source is not incremental.
Post load procedures on cloned tables to populate existing load tables. The post-load procedure on a cloned load table simply truncates the load table, then it inserts the contents of the cloned table into the baseline load table, mapped as specified per the customer.
***Critical*** - Groups/Projects. If any customization work is to occur in a customer environment, set up a Group called Custom Work with two projects:
Custom Work – Modified Objects
Custom Work – New Objects.
Give the projects the extended name, not Modified Objects, or New Objects, because the DWD tool has some issues around confusing same named Projects. Allocate any custom work done in that environment to the appropriate Project that you created. This ensures that a person can find all custom changes in one place when they get into the environment.
Customizations for a pre-domain environment (see specific document). There is a document outlining the steps for reconfiguring the baseline load tables to work with an eB2 environment. This does not contain load columns and a few other changes. Contact Services for this document. Going this route is OK, but if the customer has an eB2 environment and a post-eB2 environment, making both work is a fairly big effort. It appears to be much more efficient to have a Progress DBA create a schema in the Progress environment where the environment has mapped views of the eB2 tables and all the custom work from the document is instead mapped into the schema views. If you do this, no customizations need be done to the existing load tables. An effort is underway to provide eB2 customers with a Progress package that their DBA just installs. For now, this has only been done at customer sites by the customer’s DBA.