SBL-BPR-00214: The instance record for '%1' unexpectedly missing in operation '%2'.

Applies to:

Siebel Remote - Version: 8.0.0.2 [20412] - Release: V8
Information in this document applies to any platform.

Goal

Why Paused Task UI cannot be resumed on Mobile Client local databases after the local database being re-extracted on server and re-initialized?

And if Resume is attempted,why do these fail with errors like:
"SBL-BPR-00214: The instance record for '1E-5L' unexpectedly missing in operation 'BCReadInstance'." ? (note: '1E-5L' here is just a sample ROW_ID that can take different values)

Behaviour can be simply seen as:
-(Not OK) Tasks cannot be resumed in Local databases after DbXtract  and init have taken place!
-(OK) Tasks can be resumed fine when only Remote synchronizations are performed (but no database extracted and initialized).

Solution

From Siebel Bookshelf - Business Process Framework: Task UI Guide (Version 8.0) - Administering Task UI > Setting Up Tasks for Running on Mobile Clients > "Replicating Tasks to Mobile Clients" - can be found the following:
- "Task run-time instances - the underlying object of Task-type inbox items - are not replicated between the server and mobile clients. As a result, Task-type inbox items created at a node (such as the server) can be run only from the same node (that is, the server)."
- "Task-type inbox items created on mobile clients connecting to local databases cannot be transferred."

Looking into provided logs for the 'X-XXX' records (i.e. '1E-5L') reported in errors like:
"SBL-BPR-00214: The instance record for '1E-5L' unexpectedly missing in operation 'BCReadInstance'."
could determine that upon pausing the task, its complete status information is stored in local database tables like:
- S_TU_INST
- S_TU_LOG
- S_TU_LOG_MAP
- S_WFA_INSTANCE

And as well these details are required and read when attempting to resume the paused task!

In case that local database containing such status information is meanwhile re-extracted and initialized, these would be lost and not re-extracted from server. 

By verifying in Siebel Tools the related Docking Objects that include such tables (i.e. "Workflow Runtime", "TaskBasedUILog" and "TaskBasedUILogMap"), this also confirms same conclusion:  these Dock Objects have Visibility Level = 'Private'. Private Dock Objects tables would not be routed nor extracted from server to Remote clients (even if the upload of the same data is possible) - refer for more details to Bookshelf Guide: Configuring Siebel Business Applications > Configuring Docking Rules > "About Dock Objects".

Some workarounds that can be tested/used for such cases:

1- Warn/train end-users that upon starting remote synchronization, if they are prompted that a new database extract is available on server "Download now?", user should chose "No", stop synchronization and then review/complete first their paused Tasks.
2- if this is not helping avoiding loss of paused Task UI related information, the review and change of the standard Docking Objects could be requested via Non-Standard Change Requests (NSCR) process by engaging our Expert Services group (billable offering).

References

NOTE:475410.1 - What are the ways to troubleshoot when locally connected users cannot see records?

NOTE:475587.1 - How Should Client Side Logging Be Set?

NOTE:475652.1 - How To Log on to a SQL Anywhere (Adaptive Server Anywhere) Local Database?

NOTE:475691.1 - What is visutl and how do I run it?

Applies to:

Product Release: V7 (Enterprise)

Version: 7.8.2.3 [19221]

Database: IBM DB2 8.2

Application Server OS: Microsoft Windows 2003 Server SP1

Database Server OS: IBM AIX 5L 5.1



This document was previously published as Siebel SR 38-3353174251.

Symptoms

SBL-BPR-00214

We have reviewed our strategy w.r.t. our long running workflows. As described previously, we
were using the a Wait step to sleep for an interval, then upon resuming we would check the
activity record in question to see if it had been updated. If so, we would proceed to creating
the next activity.

This strategy, apart from being inherently process intensive, was also
unstable as per previous problem descriptions. Consequently, we decided to rather introduce User
Events as a mechanism to only resume with the long running workflow when the activity in question
is updated, at which time a UserEvent is raised. This is far more efficient than constantly
checking the activity to find out if it has been updated yet.

The strategy seemed
promising and, after a resolving a few implementation issues we have implemented the strategy.
However, we are now faced with a new problem that appears to be a product defect that could
really sink us. It would be of great value to us if you could investigate this and hopefully
assist with overcoming this problem, which I will describe in detail below.

Solution

Message 1

Hello Lindsay,



Thank you for using the Siebel SupportWeb.



For the benefit of other readers, the customer was using a User Event to resume a Long Running Workflow. A top level Workflow was used to invoke a sub process (both Long Running Workflows). The sub process waits on a particular User Event being generated. When the sub process receives the User Event, it should continue, then control passed back to top level Workflow, which decides whether to continue, or again invoke the sub process. This works fine on first iteration (control is passed back). But if the sub process is called again, and the sub process waits on the User Event again, the following error occurs :-



ObjMgrLog    Error    1    0    2007-06-05 15:35:52    (state.cpp (1253)) SBL-BPR-00214: The instance record for '1-MQAR' unexpectedly missing in operation 'BCReadInstance'.    



The instance it is referring to, was the first instance of the sub process (which has since completed, and so no longer exists)...



The behavior was re-produced, and change request 12-1JQD16E was logged with abstract “Nested long running workflows and using User Events to resume, results in error”





Siebel Technical Support



keywords SBL-BPR-00214, BCReadInstance