Whether a table needs to be added to replication, removed, or just altered the procedure is simple.
Once you have an existing replication, the following procedure should be used to change the replication.
1) Copy the existing config file to a new config file.
2) Edit the new config file to reflect the changes that are required.
3) Activate the new config file.
This activation will behave slightly differently to the initial activation, and the behavior depends on wether the table has been changed in the new config file.
For tables without changes, a brief lock will be placed on the table, a check is made that the existing table structure matches the structure in the old and new configs, and the lock will be dropped. The reason the lock is required on the table is to check that no DDL is running against the table that might impact the checks SharePlex is making.
When changes in the config file are detected for a table, the table is de-activated and re-activated. If you are not using supplemental logging (Oracle 9+) then the table will need to be analyzed to list chain headers and all the chains will need to be walked by SharePlex.
What should NOT be attempted is to edit the existing config file and activate that, as under certain scenarios where activation might fail, this approach can result in total de-activation of the config.