Publish Schema Modifications

Customizing › Web Interface Customization › How to Customize Schema Using Web Screen Painter › Publish Schema Modifications

Publish Schema Modifications

After you are satisfied with your schema modifications, you can make them available to all users by publishing them. WSP stores your new or updated tables and columns in the wsptbl and wspcol tables of the database, respectively.

Follow these steps:

Create or update files describing the modified schema to the Object Engine and to CA SDM utility programs. WSP creates the following files on the web engine designated by the wsp_webengine option (which defaults to web:local):

wsp.mods

Describes all Web Screen Painter-maintained schema changes to the Object Engine.

wsp_schema.sch

Describes all Web Screen Painter-maintained tables and columns.

wsp_index.sch

Describes DBMS indexes for Web Screen Painter-maintained tables.

wsp.altercol

Names new columns created by WSP but not yet defined to the DBMS.

wsp.altertbl

Names new tables created by WSP but not yet defined to the DBMS. In addition, WSP distributes the wsp.mods file to all CA SDM servers with an Object Engine.
Select File, Save and Publish.
The necessary files are created on the CA SDM servers, but does not recycle any of them. Thus, the new files have no immediate impact. However, after the files are created, they will be used the next time CA SDM services are recycled.
If you are using the conventional configuration, complete the following steps:
- Shut down the CA SDM services on the primary server and run the following command:
```
pdm_publish
```
  This command modifies the physical DBMS to contain information about the new schema.
  
  Important! Running pdm_publish process has a significant impact on other users. Ensure that you carefully plan the publishing of the schema changes. We recommend you use CA SDM Change Orders to schedule and obtain approval for your planned schema publication.
If you are using the advanced availability configuration, complete the following steps:
1. Execute the following command on the background server to notify all active users using Support Automation to save their work:
```
sa_server_notifier [-h] | [-q seconds] | [-c]
```
  -h
  
  Displays the help page.
  
  -q seconds
  
  This option notifies a local server (background) to quiesce in a specified time interval. This interval is the number of seconds before the server goes offline. This option cannot be used for a standby server or application server.
  
  -c
  
  This option cancels a previously sent quiesce request.
  
  A pop-up message is displayed to all the active users using Support Automation on the background server. This message notifies the users about the server shutdown and the scheduled time left for the shutdown. The users must save their work and logout within that scheduled time.
2. Shut down the CA SDM services on the background server.
  Important! Do not restart the CA SDM services on standby or application servers after "save and publish" is performed from WSP. This action corrupts the advanced availability configuration. If the CA SDM services on standby or application servers are stopped and you want to start the services, run the pdm_server_control –v command on the servers to suppress the version control before starting the CA SDM services.
  
  Important! If the background server fails during the publishing activity, ensure that you recover the WSP changes. For more information, see the Recover WSP Changes During Background Server Failure topic.
3. Execute the following command on the standby server that you wish to promote as the new background server:
```
pdm_server_control -b
```
  -b
  
  Notifies a local standby server to become the background server. The standby server must already be running. If the server is not running, it is started but no failover is performed; to start a failover, run the command again.
  
  The background server shuts down automatically and the standby server is promoted as the new background server. This change does not affect the end-user sessions. The in-progress updates (if any) are stored and delayed, until the new background server comes online.
4. Run the following command on the original background server (now the standby server) to update the DBMS with the schema changes:
```
pdm_publish
```
  The pdm_publish command creates a control file that causes the next CA SDM startup to suppress synchronizing the standby server with the background server. This action is necessary to preserve the schema file changes made by pdm_publish. This command optionally performs the second fail-over after successful publishing of the schema changes. The following message is prompted to the user at the end of successful publishing:
```
Do you want pdm_publish to start CA Service Desk Manager in this standby server and perform fail-over(Y/N)?
```
  - If you enter Y, pdm_publish starts the CA SDM services on the standby server and performs fail-over automatically. Skip to step g to apply the schema changes on all the application servers.
  - If you enter N, go to Step e.
5. Start CA SDM services on the standby server (original background server).
  The startup detects the control file that is created by pdm_publish, but does not synchronize the standby server with the background server. This lack of synchronization preserves the changes made by pdm_publish for this startup.
  
  Important! Ensure that you follow these directions exactly, as the failure to failover to the original background server after a pdm_publish results in corrupted services.
6. Run the following command on the standby server (original background server) to make it the background server again:
```
pdm_server_control -b 
```
  This command also deletes the control file, so that version control works normally when this server again becomes a standby server.
7. Execute the following command on the application servers:
```
pdm_server_control -q interval -s server_name
```
  -q interval -s server_name
  
  Notifies a local or remote application server to quiesce in a specified time interval. This interval is the number of seconds before the server goes offline. When using this option without a server_name, the local server is notified to quiesce. This option cannot be used for a background or a standby server.
  
  A pop-up message is displayed to all the active users on the specified application server. This message notifies the users about the server shutdown and the scheduled time left for the shutdown. The users must save their work and logout within that scheduled time. The users log on to the updated application server to resume their work.
8. Restart all standby servers.