Archive

Posts Tagged ‘ACS’

BOCS Implementation Contd-Single Model 2

November 15, 2010 Comments off

In my Previous Post , we have discussed the Single Model 1 implementation of BOCS. Another approach of executing BOCS can be put in Single Model 2 as in below:

Single repository with content in a distributed storage area.

In this model, content is stored in a distributed storage area. A distributed storage area is a storage area with multiple component storage areas. One component is located at the repository’s primary site. Each remote site has one of the remaining components. Each site has a full Content Server installation (a content-file server, also called a content-file server or RCS) and an ACS server installation for the repository. Content is replicated from its source component to the remaining

Components by user-defined content replication jobs. This model can be used for either web-based clients or Desktop clients. If a remote site is using web-based clients, the site should configure the use of the ACS server or a BOCS server to access content, to provide optimal performance for the web-based users. Desktop clients use the Content Server at the remote site to access content. In this configuration, metadata requests are handled by the Content Server at the primary site and requests to write content to storage are handled by the Content Servers (RCS) at the remote sites.

Note: This figure depicts geographic locations, not individual machines.

Single Model-2 Distributed Architecture BOCS

 

In this model, users in the small branch offices say in Singapore and Thailand access the content Stored in the distributed storage component at the larger India branch office. Similarly, users in the small branch offices at Europe or  Australia  access content stored in the larger Australia branch office. If the users are logging in using a web-based client, content requests are handled through the ACS server at the appropriate branch office in Australia or India. If the users are logging in using a Desktop-based client, content requests are handled by the Content Server in Australia or India. (The graphic shows only users logging in using web browsers.) In this model, the remote sites using web-based clients could have BOCS servers, rather than just a web browser, to contact the branch offices for content requests.

Benets and best use

For sites using web-based clients, this model is best if Single Model 1 is not acceptable for any particular reason. For sites using Desktop clients, this model is the only model available for a single-repository distributed configuration.

BOCS Implementation

November 13, 2010 Comments off

A BOCS server can be implemented in two different Distributed models.

Single Model-1 and Single Model -2

Lets see How a Single Model-1 Systems Works.

Single repository with content persistently stored at primary site and accessed using ACS or BOCS servers.

In this model, remote users connect through web browser, using a WDK-based client application. They access content stored at the primary site, through either an ACS or BOCS server. The ACS server is a content server dedicated to serving content. It does not process metadata nor write content to storage. It only processes content requests. The BOCS server is a separate product. It is a caching server that communicates only with ACS servers. Like the ACS server, it does not handle metadata requests or write content to storage.

Both the ACS and BOCS servers use HTTP or HTTPS protocol to serve content to clients. Single model 1 is the preferred model when remote users are accessing repository content through a web-based application, such as WebTop. There are two alternative configurations for this model. The configurations differ in how users at remote sites access the content at the primary site. In the first alternative, remote sites have a BOCS server installed and clients at each remote site use that BOCS server to access content. In the second basic configuration, users at remote sites have only web clients, and they access content using the ACS server at the primary site.

Alternative 1: BOCS servers at remote sites communicating with primary site

The Systems are not representing the individual systems or users they are representing the Geographical locations.

 

2: Remote sites, without BOCS servers, using primary site’s ACS server

 

The Model one has architecture of having single repository in an N/W distributed environment, where model one and combined form of alternatives of model one and two are very common Industry configuration, they are preferred over the alternative two for model 1. Or there can be one combined situation also when both of the configuration may exist simultaneously in a combine form, as shown in following figure. It has single BOCS server serving to all of the system irrespective of the geographical location from where the client is accessing the Content Server. But the architecture changes when we have more than one Content storage are referred by the Content server; it is explained in model 2.

 

Two alternatives for single model 1 combined

 

Benets and best use

This model requires the least amount of administrative overhead. It is easy to set up

and configure, and ongoing administration needs are minimal. There are no content

replication jobs to define, administer, and run. This model is not available for users on Desktop clients.

In my next Post , i will bring out the implementation of BOCS in Single Model-2.

ACS Implementation

November 12, 2010 Comments off

The Architecture/Implementation of ACS to the Documentum Environment can be best described as in below:

In the above figure the application can be connected to the Repository through the ACS server or can be connected directly. The ACS server may or may not be serving to all of the repositories on the content server. It will depend on the configuration that we have done (as discussed in my previous posts) , whether the ACS config object is configured for that repositories and whether the client application is specified in the Network location or not.

Prerequisites ,Installation and Configuration of ACS

November 10, 2010 Comments off

In my previous post i tried to bring out what is ACS , today lets see how we can install and configure an ACS , to start off with the Prerequisites for ACS:

a) Content Server.

b) Global registry Repository.

Installation and configuration of ACS:

Administrator doesn’t need to install it explicitly; it gets installed automatically when Content server 5.3 sp1 and above are installed. An ACS config. Object is also created automatically in the menu:

Administration-> Configuration->ACS Servers. As shown in following diagram:

 

The Administrator can check whether this service is running or not by going to following link in his system http://[system ip address]: [port no]/ACS/servlet/ACS. Or he can see the ACS service running in the services of his operating system service manager.

The Configuration of ACS means configuration of ACS server for the repository which will serve by that ACS server to specified network locations. We need to configure the ACS server config. Object for each repository, irrespective of the content server under which it is created. This configurations will be as following:

1)    Go to the Servers in Administration->configuration->Servers and click on information button to edit the properties for that server config. Object.

Go to “Connection Broker Proj” Tab and add the address of host name on which the ACS server is installed and also specify the Proximity for that Server. Administrator can add more than one connection broker to one repository at any time.

Now after following the above steps , you will see that the ACS server got added to server config object:

2)    Go to the “Network Location Proj “ tab to add the network location to be served by the repository.

Network Location got added to Server Config Object as in below:

3)    Now save and come out of the server config object to the ACS server config Object. And verify the “Connection Broker Projection” and “Network Location projection” for correct entries.

Now the ACS server is configured to the Repository server through a Connection broker to serve a set of network location.

Note: While creating the connection broker object take care for false host name because the Documentum never verifies for fake/non existing hosts.

Introduction to ACS and BOCS

November 9, 2010 Comments off

The Accelerated Content Server (ACS ) server is a content server dedicated to serving content. It does not process metadata nor write content to storage. It only processes content requests. It gets installed automatically while installing the Documentum Content Server. After installation administrator needs to configure it for distributed environment.


Branch Office Caching Services (BOCS) is a lightweight server product running in the Apache Tomcat servlet container. BOCS serves content files to Web client end users from a local content cache. BOCS servers communicate only with ACS servers and do not interact with Content Servers or a repository’s supporting database. BOCS servers cannot write content to a repository. BOCS servers use the HTTP or HTTPS protocol to serve content. BOCS is used in distributed environments. BOCS is easily installed and has minimal administration requirements. The BOCS server is supported on the same platforms as Content Server. It needs to be configured for each repository.

%d bloggers like this: