SDM: A Walkthrough of Schema Designer functionality in an Advance Availability Environment

book

Article ID: 143814

calendar_today

Updated On:

Products

CA Service Desk Manager SUPPORT AUTOMATION- SERVER CA Service Desk Manager - Unified Self Service KNOWLEDGE TOOLS CA Service Desk Manager - Mobile Application CA Service Desk Manager - Xtraction

Issue/Introduction

The following document discusses the activities that occur during a schema change in Advance Availability.  In the running example:

Server1:  Background (BG) Server
Server2:  Standby (SB) Server
Server3:  App Server

Environment

Release : 17.1

Component : SERVICE DESK MANAGER

Resolution

The basic process to make a schema change in an Advance Availability environment is as follows:

Note:  Perform all changes in sequence.  Do not consolidate commands on a given Server.

* On Server1:
- Create the schema changes that are needed.  In this case, I have created a simple table "ztesttable1" with one column testcol1 of type Integer.
- Do a save/publish
- Stop Services on BG Server

* On Server2:
- Run pdm_server_control -b to change Server2 from SB to BG

* On Server1:
- Run pdm_publish to post the changes

When you are prompted with this:
Do you want pdm_publish to start CA Service Desk Manager in this standby server and perform fail-over(Y/N)?

Select "Y"  (THIS WILL STOP SERVICES ON SERVER2 AND START SERVER1 BACK UP AS A BG SERVER)

* On Server3:
Run:  pdm_server_control -q 10 OR stop services.  Both options will result in SDM Services on Server3 to be stopped.

** AT THIS POINT, ONLY SERVER1 IS RUNNING AND IS IN BG MODE.  BOTH SERVER2 (SB) AND SERVER3 (APP) ARE STOPPED.

* On Server2
Start SDM Services

* On Server3
Start SDM Services

After the above changes are affected, you will see that on the Server1 server these WSP related schema files:

 Directory of NX_ROOT\site\mods
01/01/2020  08:44 AM               329 wsp_index.sch
01/01/2020  08:49 AM               104 wsp_schema.log
01/01/2020  08:44 AM               563 wsp_schema.sch

 Directory of NX_ROOT\site\mods\majic
01/01/2020  08:44 AM               841 wsp.mods

On Server2 and Server3, you will only see:

 Directory of NX_ROOT\site\mods\majic
01/01/2020  08:56 AM               841 wsp.mods

The important thing is that in the NX_ROOT\site\ddict.sch file of all three servers, you should find your schema changes listed and that the wsp.mods file is present across the servers as well. 

As a sanity test, one can run pdm_extract on the given table to confirm that the table or field has been updated.

Example:  I had created a table "ztesttable1" through Schema Designer.  After running through the above steps, running "pdm_extract ztesttable1" on Server1 (BG) will show:

NX_ROOT\site>pdm_extract ztesttable1
ztesttable1
        rows:0

The above command shows that the table is accessible, despite the lack of row content.  An invalid table, ie:  zJUNKTABLE, would show a result such as:

NX_ROOT\site>pdm_extract zJUNKTABLE
zJUNKTABLE is not a recognizable table.

One can also run "bop_sinfo -d ztesttable1" on Server1 (BG) and see the table structure created.

NX_ROOT\site>bop_sinfo -d ztesttable1

Factory ztesttable1
 Attributes:
   id                   INTEGER
   producer_id          LOCAL STRING(20)
   persistent_id        LOCAL STRING(60)
   testcol1             INTEGER
   last_mod_dt          DATE
   last_mod_by          SREL -> cnt.id

The same results for bop_sinfo and pdm_extract will show on Server3 (App Server) as well as on Server2, after it has been set to run as the BG Server by running "pdm_server_control -b" first.

Additional Information

The lack of the wsp_index.sch, wsp_schema.log, and wsp_schema.sch are not important on the SB and App Servers.  As long as the wsp.mods file and ddict.sch reflect the custom schema updates on the SB and App Servers, you should be fine.

As a best practise, we recommend keeping the BG Server you are making schema changes on consistent so that one server retains wsp_index.sch, wsp_schema.log, and wsp_schema.sch at all times.

See also:
https://ca-broadcom.wolkenservicedesk.com/external/article?articleId=117199