The section deals with the transition method for the database reconnect (DB reconnect)

Typically, an SAP application server collects requests from multiple front ends and dispatches them to the work processes that execute the requests, such as a specific ABAP program. Several dialog work processes run on one application server.

The transition of the dialog and batch work processes to the bridge subsystem requires a database connection to the database schema on the bridge subsystem. For the transition, the production system and the bridge subsystem must have the same start release and the same table content in the database schemas.

The advantages of this method are:

• No system downtime
• Automated procedure
• No logout and logon of users required
• Transparent for administrators
• Automated workload roll-over

The database connection must be changed for all users who are connected to the database schema of the bridge subsystem.

When the transition is started, any work process that becomes free to be scheduled for a new logon or a newly started batch job was previously idle. Such a work process is either already in the bridge database schema, or it used the idle time to perform the DB reconnect. The effect is that every new logged-in user and each newly started batch job are automatically in a work process on the bridge subsystem. The idled work processes are reconnected immediately. SUM checks the status of the Task Handler whether all tasks of the work processes are reconnected and then continues with the update procedure.

Users who are in a session without calling a COMMIT WORK are logged off when the timeout is reached. The timeout is controlled by a parameter.

If no COMMIT is set, a default value defines the maximum number of seconds for the abort case.

You can monitor the reconnect status as described in Monitoring the Reconnection of Work Processes.