Keeping Salesforce and OT in sync

mbarben

Hi There,

I am assisting a customer with an issue. The issue appears to be that when Content Server is under load (say a lot of cases are being created) there are circumstances where:

• A Workspace will be created but the xecm__BusinessObjectWorkspace__c along with the data is not recorded.
• There is no hard error
• There is a record in the logs that there was a time-out.

This leaves the solution in a situation where values in the number of xecm__BusinessObjectWorkspace__c objects in Salesforce do not match what is being recorded in the ECMLINK_WKSP_UNION view in Content Servers db.

At the moment the plan is to have an agent that will query this view and upsert the delta on a continual basis to Salesforce - but it seems that this might be a gap that is better served being solved within the solution.

I am wondering if other people have seen this issue before.

Regards,

Matthew Barben

Clarke

Hey Mathew,

Thanks for all your posts here on the Smart UI, they are very helpful.

I have lots of experience working with mass BWS creation performance. Here are all the things I recommend:

Number 1:

In your BWS Config, make sure you are using "Bulk Mode". I believe Bulk Mode mode, bypasses the OScript Layer and just uses direct SQL to create the BWS. So it is much, much faster. Like 20x faster for the creation.

I would go so far as to say it is a best practice to always make BWS configs via Bulk Mode. AKA if your not using Bulk Mode right now, that is prob why you are having problems for mass creation.

Number 2:

The otsapxecm web service still connects to Content Server via 2099 which is the LAPI port. If you don't do the ephemeral ports hack, the connection can become unstable with you crush it with BWS createOrUpdateWorkspaces

Attached is the best KBA I could find. I find it very difficult to locate KBAs now.

Hope this helps.

Regards,

-MC

KB8846942.html.txt

mbarben

Thanks for the article Clark - super helpful.

In my situation I am not only looking for the answer to the performance issue - I am looking to create a more robust solution that assumes failures (especially around asynchronous calls) and ensure that the Salesforce and OT systems are in sync.

Clarke

Hello Matthew,

I'm not very familiar with the SalesForce XECM Integration however I suspect it is much the same as the rest of them. XECM is two way Synchronization. If a User in CS Edits the Biz Props/BWS Cats and Atts CS makes a call out to the SPI WSLD.

For all the XECM scenarios I have implemented, I have never wanted the Users to Edit the metadata of the BWS, I perms them so they can't. So I make it 1 way XECM.

That leaves just the Leading Application sending changes to Content Server/XECM Platform via the otsapxecm WSDL, usually calling createOrUpdateWorkspaces. That is the actual name of the method it calls. As you can tell from the name it either creates OR updates (creates if the BWS is not there, updates it is it).

This is the outbound from the leading app that that hammers ECMLink, which hammers 2099.

If you don't run with bulk mode on, it can be like 20 to 50 seconds for a BWS to be created. If you run with bulk mode on, it is usually under 5 seconds for a create. There is no performance boost on updates. The boost is just on the create.

If you don't do the ephemeral port hack the 2099 connection can be unstable, and you get might get errors inside ECMLink. Errors like "Could not access server".

What if one of those errors was a metadata update. What happens then?

This is the scenario I believe you are talking about. Some call never makes it to CS.

In the scenarios I have worked in, this is never fixed. If the call is unsuccessful I don't believe there is a retry mechanism. The only way to get it fixed is to trigger another update, which sounds like what you are doing.

On the Custom XECM Solution I worked on, an agent was developed to crawl the BWS and check them against the leading app. If things didn't match, the Leading App would fire off a createOrUpdateWorkspaces.

Your solution sounds pretty good to me.

Regards,

-MC