dm_cram

documentum quest with community

New Documentum Exams
  • E20-485: CM Application Architecture
  • E20-475: CM Systems Architecture
Learn more >>
Resources Dashboard
  • Questions: 223
  • Tips: 86
Try some questions >>  
Community Dashboard
  • Members:5129
  • Posts: 898
Connect with others >>

dm_cram Discussion Board

 
pk4d
User

Platinum Boarder
Posts: 290
graph
Karma: 17  
Re:TBO and SBO - 2016/07/27 22:09 The answer here is from my friend Soji:

Basic Idea about TBOs and SBOs (deployed using BOF2) is that the central storage location of the code/module is the repository (Same repository as the object type for TBO, and Global Repository for SBO) BUT the execution happens on the DFC client machine (a client can be a standalone application on a desktop, webtop/d2 on an application server, or server methods, workflow methods etc on the content server). This concept can answer all the questions below.

-- TBO and SBOs are installed in which server? application or content server?

The code in the form of JAR file resides in the repository of object type dmc_jar (not content server or application server themselves).

-- They are triggered/implemented in which server?

Executed on the client machine interacting with the content server/repository as if they were just another set of DFC class and methods.
Some additional information: The TBO implementation and interface jar files are downloaded to the client machine in the BOF cache location as defined in the dfc.properties file (property: dfc.cache.dir). (D:AppsDocumentumUsercache7.2.0000.0054bofRepoName as an example. The version number 7.2.0000.0054 is the version of the DFC client that is executing the program).
When the TBO code is updated in the repository (by means of installing a composer project), the client cache should get updated when the object type is used.
A file in the cache location called content.xml has a list of these JARs and their details.

-- By default who is the session user in any TBO? Its the logged in user who triggers the particular operation..Am i correct?

The TBO uses the same session as the user that triggers the operation.

-- If there is no logger defined in TBO, where by default the TBO log gets created.

Unclear on the question.. "no logger defined in the TBO" or "for the TBO package/class in the log4j.properties/xml"?
The logging mechanism makes use of the log4j setting that is in the path of the Java used for TBO execution on the client machine. Typically, there's a log4j.properties file in the DFC config directory which should specify the defaults.


This repository/client model is for BOF2.
Benefit: One deployment per object type per repository regardless of the number of clients.

For (depcrecated) BOF1, dbor.properties on the client machine is used and the code/JAR resides on each client machine. (No composer project modules and JARs involved here)
Benefit: One TBO logic per client per object type (regardless of repository name).


Another tidbit: BOF2 has precedence over BOF1. (which means in case there are 2 TBOs are defined for the same object type - one using BOF1 and another using BOF2, the BOF2 code gets executed on the client machine)
  | | The administrator has disabled public write access.

    Topics Author Date
  thread link
TBO and SBO
J4Jayanti 2016/06/21 12:46
  thread link
thread linkthread link Re:TBO and SBO
pk4d 2016/07/27 22:09
Home
Tests
Discuss
Resources
Login
      Try IX Web Hosting