Coding and Schema Changes Made in SyteLine 9.00 for Multiple Sites per Database. White Paper

Transcription

1 Coding and Schema Changes Made in SyteLine 9.00 for Multiple Sites per Database White Paper

2 Copyright 2013 Infor Important Notices The material contained in this publication (including any supplementary information) constitutes and contains confidential and proprietary information of Infor. By gaining access to the attached, you acknowledge and agree that the material (including any modification, translation or adaptation of the material) and all copyright, trade secrets and all other right, title and interest therein, are the sole property of Infor and that you shall not gain right, title or interest in the material (including any modification, translation or adaptation of the material) by virtue of your review thereof other than the non-exclusive right to use the material solely in connection with and the furtherance of your license and use of software made available to your company from Infor pursuant to a separate agreement, the terms of which separate agreement shall govern your use of this material and all supplemental related materials ("Purpose"). In addition, by accessing the enclosed material, you acknowledge and agree that you are required to maintain such material in strict confidence and that your use of such material is limited to the Purpose described above. Although Infor has taken due care to ensure that the material included in this publication is accurate and complete, Infor cannot warrant that the information contained in this publication is complete, does not contain typographical or other errors, or will meet your specific requirements. As such, Infor does not assume and hereby disclaims all liability, consequential or otherwise, for any loss or damage to any person or entity which is caused by or relates to errors or omissions in this publication (including any supplementary information), whether such errors or omissions result from negligence, accident or any other cause. Without limitation, U.S. export control laws and other applicable export and import laws govern your use of this material and you will neither export or re-export, directly or indirectly, this material nor any related materials or supplemental information in violation of such laws, or use such materials for any purpose prohibited by such laws. Trademark Acknowledgements The word and design marks set forth herein are trademarks and/or registered trademarks of Infor and/or related affiliates and subsidiaries. All rights reserved. All other company, product, trade or service names referenced may be registered trademarks or trademarks of their respective owners. Publication Information Release: SyteLine 9.00 Publication date: October 24, 2013

3 Contents About this document... 5 Overview... 5 Shared SyteLine tables... 7 Mongoose tables that are not shared... 7 Details... 8 Schema changes... 8 Coding changes... 9 Data changes SyteLine Coding and Schema Changes Made in SyteLine 9.00 for Multiple Sites per Database 3

4 Contents 4 SyteLine Coding and Schema Changes Made in SyteLine 9.00 for Multiple Sites per Database

5 About this document This document outlines the SyteLine 9.00 coding, schema, and data changes that were made to allow multiple sites in a single application database. It is intended for administrators who upgrade from previous versions and whose systems have been customized through table or coding changes. This document can help you determine the updates you need to make to your customizations when you upgrade to SyteLine 9.00 or above. It is not intended to be a living document and will not be maintained for future releases. Overview To support multiple sites per database, we added a new site reference (site_ref) column to many of our existing tables. This column is used as a site differentiator for the data. To limit coding changes, tables where the new site_ref column was added were renamed, and a view was created which points to the new table, using the old table name. The example below shows how the item table was renamed to item_mst, which now contains a site_ref column. Then a view called item was created which points to the item_mst table: Any associated _all tables are renamed so that the _all suffix remains at the end. For example, item_all was renamed item_mst_all. An item_all view was then created that points to the item_mst_all table. If multiple sites reside in one database, the item_mst table looks like this example: site_ref Item description OH 908 Gear, 8 tooth IN 908 Gear, 8 tooth MI 908 Gear, 8 tooth SyteLine Coding and Schema Changes Made in SyteLine 9.00 for Multiple Sites per Database 5

6 Overview MI 910 Gear, 10 tooth IN 910 Gear, 10 tooth OH 910 Gear, 10 tooth OH 912 Gear, 12 Tooth IN 912 Gear, 12 Tooth MI 912 Gear, 12 Tooth MI AD Additive, UV Rays Prevention IN AD Additive, UV Rays Prevention OH AD Additive, UV Rays Prevention OH AL Steel,Chromium IN AL Steel,Chromium MI AL Steel,Chromium Connections to SQL use the SQL session constant context_info to store the site information. The generated views have a where clause that filters the data based on the context_info. Thus a query like select * from item now executes against a view that uses context_info() to filter the data for a specific site. This example shows the result of that query, assuming that context_info is set to OH: site_ref Item description OH 908 Gear, 8 tooth OH 910 Gear, 10 tooth OH 912 Gear, 12 Tooth OH AD Additive, UV Rays Prevention OH AL Steel,Chromium OH AL Steel,Chromium Alloy Sessions must set context-info in order for the views to work. (Alternatively, you can reference the actual multi-site table names (*_mst) and filter for the appropriate site.) Use this statement to set the context_info when you use SSMS: InfobarType; EXEC [dbo].[setsitesp] OUTPUT Only some tables have a site differentiating column added. In cases where no site_ref column was added, the tables were not renamed. Those tables are considered shared because they store data that is common to all sites within the database. 6 SyteLine Coding and Schema Changes Made in SyteLine 9.00 for Multiple Sites per Database

7 Overview Shared SyteLine tables These tables, in addition to persistent staging tables that is, tables which store data temporarily for a process and/or report are shared across all sites within a single database, and thus were not renamed: Workflow Event Handler Activation tables: app_workflow app_workflow_parm app_workflow_trigger_attr Dimension tables dim_attribute dim_attribute_override dim_base_unit dim_function dim_object_attribute dim_object_table_join dim_subscriber dim_unit dim_unit_prefix dimension dimension_object dynamic_table used to support some dynamic processing for some persistent staging tables fs_schedule Service Scheduling appointments inco_del_term Intercompany Delivery Terms static list iso_country ISO Countries static list iso_currency ISO Currencies static list iso_u_m ISO Unit of Measurements static list item_glbl Global Item data Mongoose tables that are not shared In most cases, Mongoose (framework) tables are shared across all sites in a single database, so the tables were not renamed. These tables are the exceptions, which were renamed: parms_mst parms_mst _all AccountAuthorizations_mst ActiveBGTasks_mst BGTaskHistory_mst EventGlobalConstant_mst SyteLine Coding and Schema Changes Made in SyteLine 9.00 for Multiple Sites per Database 7

8 Details EventQueue_mst EventTrigger_mst EventTriggerParameter_mst NextKeys_mst QueuedEvent_mst ReplicatedRows3_mst ReplicatedRowsErrors_mst ReportOptions_mst ShadowValuesErrors_mst UserGroupMap_mst The AccountAuthorizations_mst and UserGroupMap_mst tables can still be set up as shared across all sites within a single database. The SyteLine user_local table can be set up as shared across all sites within a single database. Details Schema changes To support multiple sites in a single database, these schema changes were made: For tables that are not _all tables, we made these changes: Renamed the tables to add the _mst suffix. Added a new column (SiteRef or site_ref) to distinguish site ownership of data. Specified this default value for the site_ref or SiteRef column : CONSTRAINT [DF_<table_name>_site_ref] DEFAULT (rtrim(convert([nvarchar](8),context_info(),0))) Added the new column at the end of all primary and unique key constraints and all indexes. Renamed default, check, primary, unique, foreign key, and index names based on the new table name. Adjusted SyteLine-distributed foreign keys that reference multi-site tables to conform to changes in (primary and unique) constraints. Dropped all non-syteline-distributed foreign keys that reference multi-site tables. These were not re-created. Removed full text indexes. For _all tables, we made these changes: Incorporated _mst into the name. The standard naming convention was retained (that is, base_table_name_all) so, for example, item_all was renamed item_mst_all. Removed default and check constraints on _all tables. 8 SyteLine Coding and Schema Changes Made in SyteLine 9.00 for Multiple Sites per Database

9 Details Renamed primary, unique, foreign key, and index names based on the new table name. There are no foreign key constraints on _all tables, so foreign keys should be removed. Removed site_ref from the RowPointer constraint. RowPointer will be unique to a database. A view is generated for each table based on the original table name without the _mst suffix. The view name is defined in the Application Table Metadata form. (For more information on this, see below.) A new View Management form was created to facilitate creating the views. Every time a table is changed, the view must be regenerated. Views are automatically regenerated when UET Impact Schema is performed. Coding changes To support multiple sites in a single database, we made these programming/code changes. You must make similar changes in your custom code: We renamed triggers for new table names. This change was not required, but it was done to maintain consistency. All references to the trigger name (for example, in Enable Trigger statements, etc.) must be kept in sync. We made these changes to triggers: Updated references within a trigger to other trigger names that have changed (Insert, UpdatePenultimate, and other Iups). Generated triggers are based on the table name, so the Insert and UpdatePenultimate trigger names, when generated, will contain the _mst reference. Changed table name references in the CREATE statement. Instead Of triggers do not allow recursion. In cases of recursion, we performed these steps: Moved any appropriate logic that is included in a generated Instead of Insert trigger into an Iup trigger. Updated the AppTable row to ignore the insert so that the generated trigger is not created. An example of when an insert would be ignored is this: coitem_mst programatically adds a row to the coitem_mst in another site, which could now be the same database and table as the current site. We also included logic to not insert into an _all table when all sites are in a single database. These commands are not allowed on views, so the code had to be updated to refer to the new table name: Changed Truncate statements to call TruncateTableSp. Changed Update Statistics statements to perform the action on the new table name. Updated Set Identity_Insert table references for tables that were renamed. Index hints: Rewrote any use of index hints to refer to the new table name and included an appropriate Where clause on the site_ref column. Sometimes table names are passed as parameters. Review each case to see if a change is required. In some cases, no change should be made because the name, which now matches the view name, is appropriate. In these cases, changing to the table name could have adverse effects. Here are some examples of SyteLine code that was changed: Calls to AnticipateSessionIdentitySp and ReceiveSessionIdentitySp need to be updated if they deal with a table that is renamed. SyteLine Coding and Schema Changes Made in SyteLine 9.00 for Multiple Sites per Database 9

10 Details Calls to CreateDynamicTableSp Use of IsObjectReplicatedSp As noted above, all connections to the database must now set context_info with the proper site value. WinStudio does this automatically, using the value from the configuration. External applications making their own connection must handle this manually. Background Tasks also must set context_info. These are areas that we changed: Modify.rdl files that call a stored procedure to pass in BG_SITEID as a parameter to the Sp. If the.rdl does not already have BG_SITEID, it should be added to the rdl. Modify report stored procedures that are called from an rdl to accept a parameter (@psite SiteType = NULL). Then pass this parameter to dbo.initsessioncontextsp or dbo.initsessioncontextwithusersp, whichever is being used. Modify executable (.exe) files to accept the site as an input parameter and to set the context_info in the appropriate standard way, for example, through InitSessionSp, InitSessionContextSp or InitSessionContextWithUserSp. Taskman was enhanced to map BG~SITEID~ to the site based on the configuration it is using. This value is now passed into the task that is executed. Perform a code sweep on all references to InitSessionSp, InitSessionContextSp and InitSessionContextWithUserSp to ensure that the Site parameter is included. Because SP and IDOMTH background tasks go through the IDO layer, those tasks do not need any extra code. Caution: Certain features of Microsoft SQL Server Management Studio, such as right-clicking a multi-site table and selecting Edit Top 200 Rows, and then performing an insert, update, or delete to that table, should not be used. In those features, site CONTEXT_INFO is not set, and downstream processing that performs some action on a multi-site table through the view over the multi-site table will not work properly. For example, if you delete a SyteLine job_mst row in this way, the triggers will not delete any associated jobroute_mst rows because the delete uses the jobroute view and requires that Site CONTEXT_INFO be set. For features that rely on a license, for example, the Chinese Localization and Printing Industry Pack modules: If you have base objects that access licensed features, the objects must call IsAddonAvailable before allowing site-specific functionality. If you have base forms that access licensed functionality, you must add a startup method that sets a global variable for each module. Each form then checks new global variable. Add-on specific forms are controlled through permissions. Convert references from LanguageIds_all to LanguageIds. The LanguageIds_all table was eliminated. Review and address any concerns over gaps in identity columns. The SQL Identity data type provides a unique sequential number for each added row. For a single site database, this results in a consecutive sequence. For a database that stores multiple sites, this results in the sequence being spread across multiple sites, which creates the appearance of gaps in the system that might be visible to the user. 10 SyteLine Coding and Schema Changes Made in SyteLine 9.00 for Multiple Sites per Database

11 Details Data changes We made these data changes to support the schema changes: Existing AppTable data must be updated to correct the table name and to include two new columns: AppViewName, which stores the name of the view that points to the multi-site table. Typically the view name is the original table name prior to adding the _mst suffix. SiteColumnName, which is the name of the column that distinguishes the site to which the data belongs. Typically this column is named site_ref; in some instances it is named SiteRef. However, it can be any column name. Any associated AppColumn row must be updated for the new table name. An AppTable row must be added for every multi-site table (if the row does not already exist) so the view can be created. Set the AppViewName and SiteColumnName values as described above. The TenantID and ReportOutputDirectory process defaults were moved to the site table. TenantID also exists in the intranet table, so that value is used if TenantID is null in the site table. Data in these tables includes table names that have been updated: app_table_ext IntranetSharedTable IntranetSharedUserTable IntranetSharedUserTableDefault rep_object_category SearchItem For multi-site tables that are converted from existing tables, set the object_name and to_object_name column values for rep_object_category table rows where object_type = 1 to the new multi-site table name. In rep_object_category rows for non-_all, multi-site tables that do not have RowPointer as the Primary Key, set rep_object_category.retain_site to 0. In rep_object_category rows for non-_all, multi-site tables that do have RowPointer,site_ref as the Primary Key, you must change the Primary Key. For _all, multi-site tables where RowPointer is the Primary Key, retain_site must be set to 1. For non-multi-site tables where RowPointer is the Primary Key, retain_site must be set to 1. The RowPointer must be unique across a database, including across databases that contain multiple sites. The Init Data scripts for multi-site tables cannot include a hard-coded row pointer. Perform appropriate existence checking for non- multi-site tables. For coding that relies on the existence of a license, add a row in the optional_module_mst table. This allows the system administrator to enable the code for a specific site through the Optional Modules form. Ensure that constraint messages are updated to match any changes to constraint names. SyteLine Coding and Schema Changes Made in SyteLine 9.00 for Multiple Sites per Database 11