TBO multiple repo's

Hi,

We've got a D6 SP1 installation with Oracle 10G and Websphere as AS.

We have several repository's and they're all mapped to a different docbrocker.

We have repo1 defined as global registry and we have repo2 that we use for this application. This application is a custom Webtop application that uses custom object types. We have defined TBO's for these custom object types. These TBO's are deployed on repo2.

In the dfc.properties from this Webtop application we have defined repo1 as global registry and we have the docbrockers from repo1 and repo2 provided.

Now sometimes when a user creates or import a document, we recieve following error.

Failed to save object : [DFC_BOF_WRONG_IDENTITY] LoginInfo and Principal for "repo2" docbase are not defined or wrong.

The jar files from the TBO are already downloaded once, the're in the cache folder.

We know that the above exception normally means that the global registry user isn't defined correct, but this is not the situation in this case. The actions where he uses a TBO most of the times works.

Can someone please help us to find a solution?

Thnx,

Find more posts tagged with

Comments

Francois Dauberlieu

Bert,

Since you defined Repo1 to be the global repository for TBO's, ALL TBO's should be stored in it, independently of the repository used. I guess in your situation, Dctm gets a bit 'confused' as soem of your TBO's are in the other repository

BertMoons

Hi Francois,

Thanks for your suggestion.

But we followed the concept of the global registry here. In the DFC Dev guide there is a definition from the Global Registry:

Global Registry: DFC delivers SBOs from a central repository. That repository’s registry is called the global registry.

When we should deploy our TBO's at the global registry then we also need to create our custom types at the global registry.

This seems like lots of overhead to me and I don't think that this is the purpose of the Global Registry.

This means then that we have to deploy all our applications in the Global registry and in the repository that we use for our application.

Thanks,

Bert

mszurap

Global registry is used only for SBOs. TBOs are stored per repository, independently from other repositories. You can check this: TBOs work even when you don't give the right credentials in the dfc.properties file for the dfc.globalregistry section.

I don't know why do you get such error messages. A Support Request may will help you.

Francois Dauberlieu

My bad, should have read the question properly instead of skimming through it

Even though the jar files are already downloaded, every time the TBO is called, it checkes if there is a new version which is why it connects to repo 2.

What do the Webtop logs say besides the one line you gave in your post and the repository logs ?

Have you checked with your network admins that there are no problems between your app server and your content servers/docbrokers ?

BertMoons

Thnx for the help.

It is strange that it most of the times works and it sometimes fails. The network should be stable, this is our acceptance environment. But thnx for the tip.

We started to loop trough the stack trace and it seems that I was a bit wrong in my first post. Sorry. He finds the TBO but he can't get a session in our code.

In the DetermineStorageLocations class, we pass the sessionManager and the repository from the TBO. Than in the next method, we do sessionManager.getSession(repo2) This seems to cause the error.

We're going to add some extra logging and see where it goes wrong.

So if he can't get a session by sessionManager.getSession(repo2) in the TBO he gives a DFC_BOF_WRONG_IDENTITY.

Thnx for the tips. We'll try to figure out what is causing the invalid sessionManager.

DfIdentityException:: THREAD: Timer-2936; MSG: [DFC_BOF_WRONG_IDENTITY] LoginInfo and Principal for "PPBD_acc" docbase are not defined or wrong.; ERRORCODE: 1906; NEXT: null
    at com.documentum.fc.client.impl.session.SessionManager.getSessionFromFactory(SessionManager.java:99)
    at com.documentum.fc.client.impl.session.SessionManager.newSession(SessionManager.java:68)
    at com.documentum.fc.client.impl.session.SessionManager.getSession(SessionManager.java:158)
    at com.nl.essent.documentor.usecase.storagelocations.DetermineStorageLocations.determineStorageLocations(DetermineStorageLocations.java:154)
    at com.nl.essent.documentor.bof.tbo.impl.EssPrdDocument.doSave(EssPrdDocument.java:49)
    at com.documentum.fc.client.DfPersistentObject.saveEx(DfPersistentObject.java:861)
    at com.documentum.fc.client.DfPersistentObject.save(DfPersistentObject.java:856)
    at com.nl.essent.documentor.bof.tbo.impl.EssPrdDocument___PROXY.save(EssPrdDocument___PROXY.java)
    at com.documentum.operations.nodeactions.inbound.impl.DfCheckinObject.checkin(DfCheckinObject.java:283)
    at com.documentum.operations.nodeactions.inbound.impl.DfCheckinObject.execute(DfCheckinObject.java:76)
    at com.documentum.operations.nodeactions.inbound.impl.DfInboundCompoundNodeAction.execute(DfInboundCompoundNodeAction.java:62)
    at com.documentum.operations.steps.impl.DfCompoundCreateSetAndCheckinObject.createSetAndCheckinDescendents(DfCompoundCreateSetAndCheckinObject.java:139)
    at com.documentum.operations.steps.impl.DfCompoundCreateSetAndCheckinObject.execute(DfCompoundCreateSetAndCheckinObject.java:72)
    at com.documentum.operations.impl.DfOperation.execute(DfOperation.java:437)
    at com.documentum.web.contentxfer.DFCOperationSupport.execute(DFCOperationSupport.java:61)
    at com.documentum.web.contentxfer.ContentTransferService.execute(ContentTransferService.java:378)
    at com.documentum.web.contentxfer.JobAdapter.execute(JobAdapter.java:107)
    at com.documentum.job.async.AsyncJobManager$AsyncTimerJob.executeJob(AsyncJobManager.java:236)
    at com.documentum.job.async.AsyncJobManager$AsyncTimerJob.run(AsyncJobManager.java:215)
    at java.util.TimerThread.mainLoop(Timer.java:527)
    at java.util.TimerThread.run(Timer.java:477)

Francois Dauberlieu

Instead of sending the session manager, what about you'd send the repository name, the user name and the login ticket to your class and use them to get a session ?

BertMoons

Thnx, this was what we're doing now, it works fine. We didn't get the error anymore. We're now going to do a bulk test to see if it is resolved.

Thanks,

Francois Dauberlieu

No probs

Rose-Line

We had also the problem that we've got sometimes the error

Failed to save object : [DFC_BOF_WRONG_IDENTITY] LoginInfo and Principal for "repoXY" docbase are not defined or wrong.

The reason was that the system clocks of the web app server and the dctm server had a delta of more than 3 minutes and the tolerance for the login ticket timestamps is only 3 minutes. Synchronizing the clocks solved the problem :-).

Francois Dauberlieu

Good one, well spotted