These are few guidelines for the BCC merchants(BCC
users) and SAs that should be followed in using BCC.
This section is intended for
all type of audience.
1. Use IE/Mozilla browsers. Any other browser
is not recommended by ATG.
2. BCC documentation is available online for
reference.
3. Avoid using back button in BCC. Use the
links to browse thru the pages.
4. Never use ACC to update any versioned
repositories viz ProductCatalog, PriceLists, coupons and Promotions. However if
any emergency updates are made using ACC then the same changes should be redone
and deployed using BCC prior to any other deployments using BCC.
5.
If
a project is scheduled for the deployment and there is another project which is
working on the same asset approved for deployment then you may see this error:
Since the
project is scheduled for deployment, so until the deployment completes, the
assets are locked. In this condition the other project will face the asset lock
error message. So until the previous project is deployed this project cannot be
approved for deployment.
This section is mainly
intended for BCC merchants.
6.
Production
BCC outage halts any work of BCC merchants but there will not be any impact to
the store customers.
7.
ACC
can be used for EMERGENCY changes but these changes are limited for updating
existing items but cannot create/delete items. When you make such emergency
changes via ACC you need to redo those changes immediately after BCC is up and
deploy the changes.
8.
Incase
BCC is down for long time and ACC is used to update the changes then it usually
takes 2 days effort to sync up BCC with prod. You will not loose your logins or
settings but will loose all the projects and version history of assets as they
went out of sync.
9.
Inventory
or any other non-versioned data managed from BCC doesn’t affect with BCC
outage. ACC can be used at anytime without any restrictions. ACC and BCC will
always be in sync for non-versioned repositories.
10. Avoid full cache invalidations to
repositories of Production environment at peak business hours.
11. If the deployed Product Catalog assets are
not reflected in any case then most likely CatalogMaintenanceService job failed
to run on agent.
In that case CMS can be invoked manually
from dyn/admin of agent server followed by cache invalidations on all agents.
This section is mainly
intended for BCC merchants.
12. Preview users should be properly created as
per guidelines in BCC documentation.
13. Do not use logout button from preview page
which logouts BCC, its ATG limitation.
14. Preview server is not a full fledged end-end
Store application.
15. Preview environment shows only changes
related to that project and base version. Other dependent project changes
deployed to staging will not be available in preview environment.
16. Staging server should be used to verify
end-end functionality.
This section is mainly
intended for BCC merchants.
17. Use export/import feature of BCC to achieve bulk
updates to versioned repositories.
18. Avoid running SQLs directly on
production/staging database to update versioned repositories. The drawbacks
using sql scripts in versioning environment is you will be losing version
history which defeats one of the key features of CA. To keep the CA, staging
and PROD instances in sync you need to run the sql files in all 3 environments.
This section is mainly
intended for SA team.
19. It’s highly recommended to start BCC server,
Preview server, Stage Server and Prod servers in order.
20.
Before
restarting the CA servers make sure there are no current deployments in BCC using
BCC Admin console.
21. Passwords should be changed to users admin and
publishing in BCC.
22. Be default on Staging/Production servers
ProductCatalog/PriceLists is readOnly in ACC for all accounts. To give edit
access to the user add “content management group” group to their login.
23. It’s recommended for SAs to have their own
logins with Super-Admin roles.
24. To invoke CMS manually, BCC deployments must
be halted first using BCC admin console and then CMS should be triggered.
Go to BCC Home>Content
Administration>Admin Console>Overview>Staging/Production
25. If any new server is added to Prod Cluster
new agent has to be created using BCC admin console.
Go to BCC
Home>Content Administration>Admin
Console>Configuration>Staging/Production
After giving
AgentName, rmi host and port save the changes.
Then Go to
Configuration Click “Make Changes Live”.
26. To delete any stuck/limbo projects in BCC execute
the following procedure. Data team should provide the projectName, creation
date/start date and current state of the project.
To delete any
stuck projects execute the following sqls in CA schema where projectName is the
name of the project to be deleted.
-- Removing locks of the project if any
delete from avm_asset_lock where
workspace_id in
(select id from avm_devline where name in
(select workspace from epub_project
where display_name='ProjectName’
and creation_date like TO_DATE('Sep 27, 2010 1:10 AM', 'MON DD, YYYY
HH12:MI AM') and completion_date is null));
-- delete history of the project
delete from EPUB_PR_HISTORY where project_id
in
(select project_id from epub_project where
display_name='ProjectName' and creation_date
like TO_DATE('Sep 27, 2010 1:10 AM', 'MON DD, YYYY HH12:MI AM') and completion_date
is null);
-- delete the project
delete from epub_project where
display_name='ProjectName' and creation_date
like TO_DATE('Sep 27, 2010 1:10 AM', 'MON DD, YYYY HH12:MI AM') and completion_date
is null;
-- delete history of the process
delete from EPUB_PROC_HISTORY where
process_id in
(select process_id from epub_process where
display_name='ProjectName' and creation_date
like TO_DATE('Sep 27, 2010 1:10 AM', 'MON DD, YYYY HH12:MI AM') and completion_date
is null);
-- delete task information of process
delete from EPUB_PROC_TASKINFO where id in
(select process_id from epub_process where
display_name='ProjectName' and creation_date
like TO_DATE('Sep 27, 2010 1:10 AM', 'MON DD, YYYY HH12:MI AM') and completion_date
is null);
-- delete states of project (if any)
delete
from EPUB_IND_WORKFLOW where process_id in
(select process_id from epub_process where
display_name='ProjectName' and creation_date
like TO_DATE('Sep 27, 2010 1:10 AM', 'MON DD, YYYY HH12:MI AM') and completion_date
is null);
-- finally delete the process
delete from epub_process where
display_name='ProjectName' and creation_date
like TO_DATE('Sep 27, 2010 1:10 AM', 'MON DD, YYYY HH12:MI AM') and completion_date
is null;
commit;
Invalidate
below repository caches in BCC server.
/atg/epub/PublishingRepository
/atg/epub/version/VersionManagerRepository
a. Whenever the deployment fails stop the deployment
and then resume the deployment.
b. If above case didn’t resolve cancel the deployment
and deploy again.
c.
Never use
rollback if deployment fails which require snapshot initialization. This is
required during Full deployment which catalog team should never do.
28.
You
cannot roll back deployment on a target site while an active deployment is in
progress on that site. If the roll back operation is urgent, you must first
revert all active deployments.
29.
During
deployment CA expects the agents of the site are in sync with respect to the
datasources. In case if you switch manually one of the agent live datasource
then during prepare to deploy action it logs an error message:
“cannot deploy to target
'Production' because switch configured agents 'PublishProdAgent' and
'PublishProd1Agent' do not have the same live data store : 'DataSourceB' !=
'DataSourceA'”.
In
this case you have to stop the current deployment and contact SAs to fix it. As
general never work on datasoruces.
30.
The
deployment fails when the essential agent server is down. It logs the message:
“/atg/epub/DeploymentServer Failed to connect to agent
'PublishProdAgent'. This agent not
allowed to be absent for a deployment.
The server will continue attempts to intialize the connection. Set loggingDebug to true for continued
exception and stacktrace logging.”
Contact SA’s to start the essential agent server.
Once the essential agent server instance is up the deployment will
automatically resumes.
31. During the switching if any target servers
is down due to some unknown reason then switching will be aborted by agent and
agent’s status will be set as “Transport Uninstantiated”. The deployment will be failed. BCC
server will keep on polling to the target instance until it’s up and once the
target instance is up, we have 2 options either to rollback the deployment or
resume it manually in Admin Console of BCC. If manually resume the project then
the switching is performed on the target and deployment will be completed.
32.
In
a clustered environment if one of CA server stopped/restarted during a
deployment initiation then you cannot access the deployment from other CA
server; the Details tab for the deployment target does not display the usual
deployment options, such as resume, stop, and roll back. Instead, it displays
the following error message:
“An RMI error encountered calling remote current deployment
'deployment-id' to target 'Production': getStatus() may or may not have been
passed to the running deployment”
'deployment-id' to target 'Production': getStatus() may or may not have been
passed to the running deployment”
After the initiating server restarts, all available
actions that pertain to the deployment become available again, and are
accessible from any CA server in the Content Administration cluster.
Very useful information. Thanks for sharing
ReplyDeleteThank you for this. Useful post.
ReplyDelete