Retain Your Modifications

Before you upgrade, consider the following information to retain the modifications that you have made:
Before you upgrade, consider the following information to retain the modifications that you have made:
  • Any “modifications” or “adaptions” or “configurations” that are done administratively through the interface (web browser, command-line, Web Screen Painter) are “supported”, meaning CA Support can assist with the basic suggestions and troubleshooting. CA Support do NOT perform any changes for the customer. The customer is responsible for the changes made. For example, adding a field to a table and putting the field on a form through Web Screen Painter is a fully supported “modification”. Similarly, installing or uninstalling a feature through the Options Manager administration is a fully supported “configuration”. Anything to do with SPEL code, Java scripting (or any language scripting), or a customer-specific change to the underlying base code-line (done by CA Services or a Partner), is NOT supported by CA Support. The customer can perform these actions, but is responsible for the support, maintenance, and troubleshooting when an issue occurs. If such “customization” affect expected out-of-the-box behavior, CA Support will ask the customer to remove the customization and see if the behavior persists.
  • Modified Reports
    -- When you modify the reports that access database tables from previous versions and that have been moved to renamed tables, the column names have been changed in Release 14.1.
  • Modified Forms
    -- Upgrade retains the modification of the forms from the previous release of CA SDM. However, you cannot view the CA SDM Release 14.1 functionality on the modified forms after you upgrade.
  • Modified Admin Tree
    -- When you modify the Admin tree in CA Service Desk Manager r11.0, these changes are not upgraded due to modifications in the architecture to support the role-based user interface. These Admin tree modifications include the addition of new nodes, renaming of existing nodes, modifying access types, or other data alterations. To use the modifications, perform the following actions:
    1. Before you upgrade, review your CA Service Desk Manager r11.0 Admin tree and note any modifications that you want to use after the upgrade.
    2. After the upgrade completes, identify which roles have Admin tree modifications.
    3. Apply the modifications to the appropriate CA SDM Release 14.1 role-based Admin trees.
    4. Review and test to verify that the desired functionality has been retained.
  • Modified Form Buttons
    -- After the upgrade completes, buttons on modified forms in
    that did not have quotes around the msgtxt(n) part of the code result in an error message, instead of the button name.
    For example, in the detail_cr.htmpl form, modify msgtxt(441) with quotes as follows to display the correct button name:
    ImgBtnCreate("btnchg", "msgtext(441)", "detailSave('NEW_CHANGE')", true, 0, msgtext(440)); // Save and Create Change Order
  • Retaining Modifications
    -- When you need the CA SDM Release 14.1 functionality and would like to preserve your modifications from a previous release then redo the modification on a base CA SDM Release 14.1 form, which has the Release 14.1 functions. When any form is modified, the customer changes are overwritten and has to be recreated. There is a process in the upgrade that attempts to detect and identify the differences in the forms, and reports it to the customer for their investigation. However, it is highly recommended to document your customization BEFORE you perform any upgrade. In some cases, a new feature may be similar to the user customization, so the user changes must be removed. The custom JavaScript file must be customized again according to the base release 14.1 JavaScript file. For more information, see JavaScript Modification.
    When you modify the
    reports, then the return data in CA SDM Release 14.1 is obsolete.
  • Notification Rules
    -- When you remove the default activity notifications Contact, Object Contacts, and Contact Types from the previous installation of CA SDM and want to retain this functionality, then note the default contacts removed before migration. After you upgrade to the new version, remove the default Notification contacts again.
  • Role-based Functionality
    -- Upgrading can cause issues with the role-based functionality. If you modified any of the following forms, they are considered as read-only by the Web Screen Painter in CA SDM Release 14.1 and they include an xxx_site.htmpl version where you can use custom code:
    • ahdtop.htmpl
    • menu_frames.htmpl
    • reports.htmpl
    • std_body.htmpl
    • std_footer.htmpl
    • std_head.htmpl
    • styles.htmpl
    • msg_cat.js
    • menu_frames_role.htmpl
  • Modified HTMPL Files
    -- Consider the following information:
    • All modified HTMPL files retain their default menu bar settings after you upgrade. A pop-up window inherits its menu bar from the main page tab, as a result of the role-based user interface. Modified HTMPL files are not available on the modified forms from the previous release after the upgrade.
    • CA SDM Release 14.1 does not use some modified HTMPL files from previous releases. The migration script executes the perl script $NX_ROOT/bin/
      that appends the files with the
      extension. After migration completes, open $NX_ROOT/site/web_check_files.txt with a text editor to see the list of incompatible forms for Release 14.1.
    • If you modifiedthe list_dblocks.htmpl file in a previous release of CA SDM, this form does not work in CA SDM Release 14.1. If you modifiedthe Admin Tree to display the list_dblocks.htmpl in other parts of the tree, the modification does not work after you migrate. Modify the form manually to use the new URL and form. To complete this modification, click Security and Role Management, Menu Tree Resources and open Current Locks. Update the resources with the following CA SDM Release 14.1 string:
  • Foreign Keys
    -- When the upgrade process detects referential integrity issues while attempting to reset foreign keys then the errors appear in the migration.log file. The associated foreign key sets to a predefined valid reference.
  • Servers and Web Director Configuration
    -- When your previous installation was configured to use additional servers or web directors, then you must first create the configuration for the specific servers and run the CA SDM server configuration utility (pdm_configure).
    CA Support Automation Divisions
    -- When you migrate the divisions to tenants, then convert this data before enabling and configuring Support Automation in CA SDM Release 12.9.
  • Rename Modified HTMPL Forms 
    – If you modified HTMPL forms in a previous release of CA SDM, you run a script to rename them before you upgrade. You run this script on all CA SDM servers. The script renames all modified web forms, style sheets, Java scripts, images, and macros in the site/mods directory. Renaming these files helps you identify your modified forms.
    Follow these steps:
    1. From a command prompt, executepdm_perl $NX_ROOT/bin/
      The script appends the modified forms with an 
    2. Open $NX_ROOT/bin/ with a text editor.
      A list of incompatible forms for Release 14.1 appears.
    The script does not restore files from backup folders to the legacy or site/mods directories as in previous releases of CA SDM.