Applies to:
Product Release: V7 (Enterprise)Version: 7.7.2 [18325] Com/Med
Database: Oracle 9.2.0.4
Application Server OS: Sun Solaris 9
Database Server OS: Sun Solaris 9
This document was previously published as Siebel SR 38-2902660931.
Symptoms
SBL-BPR-00125Hello,
When using a user interact step in a Interactive workflow,workflow gets suspended
& we get a error message saying that "workflow has already run to completion".
I am
invoking the workflow using script & putting a runtime event at the branch going out of user
interact step.
I am sending you the error log,two workflows(Prototype & main
workflow),error message & the script used to invoke a workflow
Can you please provide
us the status of the product enhancement or any alternative solution or a workaround for this
problem ?
Thanks and Regards
Solution
Message 1
For the benefit of other readers, the following problem was encountered.Assume a process designed as Start > User Interact > End, where the branch between the User Interact step and End step is triggered by a Run-Time Event (RTE). There is no Default String for process property Object Id.
a. If the process is run from the BS simulator without passing RowId, when the RTE is triggered the following error occurs.
SBL-BPR-00125: Cannot resume process '%1' for object '%2'. Verify that an instance does exist and that it has a 'Waiting' or 'Suspended' status.
b. If I run it from the BS simulator passing RowId it works, the workflow is resumed correctly.
The couple RTE-workflow works on the context. When the RTE starts the process (as opposed to resume as in above test), the [Object Id] is initialized with the Id of the current record. In above case a. the workflow mechanism around RTE/resume process does not register the suspended instance in corresponding table because there is no context and therefore when the RTE tried to resume the process it did find anything. In case b., insert into corresponding tables occurred and later on the process could be resumed.
In customer's case the process was started from a script without passing any id because the record was created in one of the steps before the User Interact. One solution was to set the context once the record created.
Continue ...
Message 2
... Part 2For instance, assume the process below (base on busobj "Service Request", Mode=Interactive Flow).
Start > Siebel Operation: Create SR > BS: Workflow Utilities/ Method:Echo to set Object Id with Siebel Operation Id > User Interact waiting for RTE (custom button) > Create Activity for the SR > End.
In the third step, the process property [Object Id] is initialized with the id of the newly created record (which the id is in process property "Siebel Operation Id"). This sets the context. In this case it works, even if the process is called without passing the RowId.
Generally speaking, workflow processes working with RTEs are started by a RTE, hence, in this case the matter of context is transparent, as opposed to this case.
, Technical Support.
Applies to:
Product Release: V7 (Enterprise)Version: 7.5.3.4 [16180] Com/Med
Database: Oracle 9.2.0.2
Application Server OS: Microsoft Windows 2000 Advanced Server SP 3
Database Server OS: Sun Solaris 5.8
This document was previously published as Siebel SR 38-1197407911.
Symptoms
We are currently working on a First Time login process. This process was designed to be controlled by a user interaction workflow which guides the user through a pre-defined sequence of registration views.We have built the workflow to the design but have encountered an error when running this workflow.
Cannot resume process '1-SW0W9' for object '1+6U+19'. Verify that an instance does exist and has a 'Waiting' status.(SBL-BPR-00125)
I have searched support web and found that someone has raised an SR which describes our problem exactly (SR# = 38-1073992777).
The Siebel response on this SR is that it’s a known bug and that an enhancement request has been logged. Is this still the case?
Best Regards
Loy
Solution
Message 1
For the benefit of our readers.The customer received an error message in the course of testing a vanilla workflow process, 'User Registration Forgot Password Process', which has a User Interact step giving them an error during runtime.
2 error messages were provided by the customer.
Cannot resume process '1-SW0W9' for object '1+6U+19'. Verify that an instance does exist and has a 'Waiting' status.(SBL-BPR-00125)
Cannot resume process '1-TERA7' for object '1+6U+19'. Verify that an instance does exist and has a 'Waiting' status.(SBL-BPR-00125)
These errors referenced 2 different process ids so we needed to confirm their existence by taking the following validation steps.
1. Navigating to Business Process Administration > Workflow Processes view and query the list applet using the following command. This will confirm if the runtime events rules are pointing the correct active process id.
Id=1-SW0W9 OR Id= 1-TERA7
2. If the above Ids do not correspond to the correct active process for the 'User Registration Forgot Password Process', then query for the active workflow process and note the row id.
3. Navigate to the Runtime Events Administration > Events view and query for Object Name = User Registration Forget Pwd*, and this should give you a list of events that correspond to the user interact step in your workflow process.
...continued...
Message 2
...2/3...4. Each User Registration event has an Action Set Name which is a hyperlink. Click on the hyperlink and this will take you to its related Action Set. There should only be 1 action in the Action applet and this action should be referencing the active process id you noted earlier. In the More Info applet, note the Business Service Context field which holding the process id info which this action set is using.
5. If your action set consist of more then 1 action then delete the one that is pointing to the wrong process id.
6. Check through all the User Registration Forget Pwd* events and ensure their action set/action is pointing to the correct active process id.
7. If you only have 1 Action/Action Set/Event and it does not have the correct process id then you need to:
a. Delete all the actions for these action sets
b. Reload Personalization (in Runtime Events Administration to clear cache)
c. Navigate to workflow process view and query for the active process.
d. Revise this process
e. Deactivate the Active process
f. Activate In Progress process
g. Navigate to Runtime Events Admin view and reload personalization again
h. Verify that the action sets are now pointing to the correct active process id.
Conclusion:
It appears that somehow during the course of customer's testing they have activated, deactivated
...continued...
Message 3
...3/3...or deleted the process several times which cause the action set to cache the inactive process Id which needs to be revised in order to point to the correct active process id used during testing.
After performing the above steps, the customer confirmed that this resolved their error messages.
Thanks,
Siebel Technical Support
Applies to:
Siebel Field Service - Version: 7.7.2 [18325]z*OBSOLETE: Microsoft Windows 2000
Product Release: V7 (Enterprise)
Version: 7.7.1 [18306]
Database: Oracle 9i
Application Server OS: Microsoft Windows 2000 Advanced Server SP 4
Database Server OS: Sun Solaris 9
This document was previously published as Siebel SR 38-1531451441.
Symptoms
Customer wanted to populate "Agent Committed" field on Service Request. When the "Verify" button was clicked, the Entitlement Pick Applet pops up and an entitlement record selected. On SR, Entitlement field is filled, the Metrics view under SR has the record of "Respone Time" but for some reason, it is not filling the "Agent Committed" field.Looked at the Log file, for some reason it is throwing this line...
ObjMgrLog Error 1 0 2004-09-29 23:27:24 (procinst.cpp (206)) SBL-BPR-00125: Cannot resume process '1-5I4TR' for object ''. Verify that an instance does exist and that it has a 'Waiting' or 'Suspended' status.
Cause
During investigation, a few issues were discovered that attributed to the workflow not working correctly to set the commit time:Issue # 1: The workflow process' runtime event did not correspond to the applet button's method being invoked
Issue # 2: Workflow Process initiated and resumed correctly, but did not set Commit Time on the Service Request
Solution
The customer was trying to get the seeded workflow process "FS - Verify Entitlement SR" to work against their server database. Against a sample database, the workflow procesw was initiated correct, resumed correctly and finally also populated the Service Request's Commit Time accordingly. However, the same workflow failed on the server database.During investigation, a few issues were discovered that attributed to the workflow not working correctly to set the commit time:
Issue # 1: The workflow process' runtime event did not correspond to the applet button's method being invoked:
1. The workflow process behind the UI > Service Request > Verify button is the following:
WF Process: FS - Verify Entitlement SR
Start step has a runtime event:
Event Object Type: Applet
Event Object: Service Request Detail Applet
Event: InvokeMethod
Subevent: VerifyEntitlement
Goes to a wait step also resumed by runtime event:
Event Object Type: Applet
Event Object: Service Entitlement Pick Applet
Event: InvokeMethod
Subevent: PickRecord
a. Please ensure that the same workflow process has been deployed to the server database. It should be visible in the Siebel Client > Business Process Administration screen > Workflow Deployment view:
In the Repository Workflow Process list, there should be one with:
Name: FS - Verify Entitlement SR
Status: Completed
Activate this workflow process.
In the Active Workflow Process list, there should be one with:
Name: FS - Verify Entitlement SR
Deployment Status: Active
Set the Monitoring Level = Debug
b. After activating the above workflow process, ensure to reload runtime events since the start and wait steps are initiated by runtime events. Do so by navigating to Administration - Runtime Event screen > Events list > menu > Reload Runtime Events.
In the Events list, query for the following:
Subevent: VerifyEntitlement
This should return an entry. Drilldown into the Action Set Name hyperlink. In the More Info applet, inspect the Business Service Context field, it should display a string similar to:
"ProcessId", "1-3MBCX"
Verify the row id matches the active version of the workflow process in the Siebel Client > Business Process Administration screen > Workflow Deployment view > Active Workflow Process list.
Then, requery Events list again for:
Subevent: PickRecord
Again, this should return an event. Go to Action Set Name > More Info, inspect the Business Service Context field, it should display a string similar to:
"ProcessId", "1-3MBCX", "StepId", "1-9JH-UXGA"
Verify the process id matches and that the step id corresponds to the row_id of the workflow process' wait step in Siebel Tools.
2. When customer set personalization logging and client-side logging, it was found in the personalization log file that the "VerifyEntitlement" event which initiates the workflow process never occurred. However, the "PickRecord" did occur which tried to resume the workflow process
The problem encountered here is that since the "VerifyEntitlement" never occurred, the "FS - Verify Entitlement SR" workflow process never ran and thus there is no waiting or suspended process instance for "FS - Verify Entitlement SR" that exists. Thus, when the PickRecord event occurred which tries to resume the workflow, there was no waiting instance for the workflow to resume, this resulted in an error message in the client-side trace file:
ObjMgrLog Error 1 0 2004-09-29 23:27:24 (procinst.cpp (206)) SBL-BPR-00125: Cannot resume process '1-5I4TR' for object ''. Verify that an instance does exist and that it has a 'Waiting' or 'Suspended' status.
3. Upon further investigation to find out why the "VerifyEntitlement" event never occurred, it was revealed that the customer had modified the applet which had the <Verify> button. There were some modifications made to the Method Invoked property for the button which caused the incorrect method to be invoked when the <Verify> button was clicked:
Customer's modified <Verify> button configuration:
----------------------------------------------------
Caption: Verify
Field: Entitlement Name
HTML Type: MiniButtonEditNew
Method Invoked: EditField
Name: Verify Button
Parent Name: Service Request Detail Applet
Pick Applet: Service Entitlement Pick Applet
Runtime: TRUE
Visible: TRUE
Vanilla <Verify> button:
----------------------------------------------------
Caption: Verify
Field: Entitlement Name
HTML Type: MiniButtonEdit
Method Invoked: VerifyEntitlement
Name: ButtonVerify
Parent Name: Service Request Detail Applet
Pick Applet: <blank>
Runtime: FALSE
Visible: TRUE
Note some of the differences, especially with the "Method Invoked" property. The modified version of the applet is using the "EditField" method instead of the "VerifyEntitlement" method. "EditField" method was not relevant to the workflow process in question.
The workflow process runtime event is based on "VerifyEntitlement" and not "EditField". Once the fixed this to use "VerifyEntitlement", the workflow process now runs as a result of the <Verify> button clicked. The "VerifyEntitlement" can be seen in the personalization log file.
Issue # 2: Workflow Process initiated and resumed correctly, but did not set Commit Time on the Service Request
1. The next problem encountered was that the workflow process goes to completion, but the Service Request's Commit Time was still not populated, it was left blank. Upon reviewing the customer's log file, it was found that the workflow issued a query to look for the Entitlement's Metric, but returned an error. The sql which failed seems to be the following:
SELECT
T4.CONFLICT_ID,
T4.LAST_UPD,
. ....
....
T4.SCHED_CAL_ID,
T3.EXCPT_CAL_ID
FROM
SIEBEL.S_SVC_METRIC T1,
SIEBEL.S_LST_OF_VAL T2,
SIEBEL.S_SCHED_CAL T3,
SIEBEL.S_ENTLMNT_MTRC T4
WHERE
T4.SCHED_CAL_ID = T3.ROW_ID (+) AND
T4.SVC_METRIC_ID = T1.ROW_ID AND
T4.PRIORITY_CD = T2.NAME AND T2.TYPE = 'SR_PRIORITY' AND T2.LANG_ID = :1 AND
(T4.AGREE_ID = :2 AND T1.NAME = :3 AND T2.VAL = :4)
ObjMgrSqlLog Detail 4 0 2004-10-18 14:55:16 Bind variable 1: ENU
ObjMgrSqlLog Detail 4 0 2004-10-18 14:55:16 Bind variable 2: 1-ELM-454
ObjMgrSqlLog Detail 4 0 2004-10-18 14:55:16 Bind variable 3: Response Time
ObjMgrSqlLog Detail 4 0 2004-10-18 14:55:16 Bind variable 4: 3-Medium
ObjMgrSqlLog Detail 4 0 2004-10-18 14:55:16
***** SQL Statement Prepare Time for SQL Cursor with ID 8FCF770: 0.053 seconds *****
ObjMgrBusServiceLog Error 1 0 2004-10-18 14:55:16 (entitlementservice.cpp (2750)) SBL-SFS-00118: Service Metric cannot be found
The SQL is checking the Entitlement's Metric for one that corresponds to SR Priority of level "3-Medium".
When checking against the customer's Entitlement > Metric screenshot, there is only one metric created for the Entitlement, it has a Response Time for Priority = "2-High", response time of 2 hours.
But from the SQL, it is trying to look for a Response Time for a Priority = "3-Medium" on the service request. There is no metric for this priority level, thus the message about "Service Metric cannot be found".
2. Customer addressed this by adding the additional Metric information for Priority = "3-Medium". However this still did not help, the Commit Time was still left blank.
3. Lastly, it was discovered that there is a set of System Preferences for the Entitlements, which controls the verification of Entitlements. These System Preferences can be found in Site Map > Application Administration > System Preferences:
Entitlement: Pricing Dates
Entitlement: Verify Consumer
Entitlement: Verify Dates
Entitlement: Verify Product
By default, they are all set to TRUE.
In customer's case, they are verifying Entitlement for Products on the Service Request and the Entitlement Dates. Customer checked against their current settings and found that "Entitlement: Verify Product = FALSE", which is not correct since they do want to verify Products. Thus, customer set this to TRUE, so that their System Preferences are now:
Entitlement: Pricing Dates = FALSE
Entitlement: Verify Consumer = FALSE
Entitlement: Verify Dates = TRUE
Entitlement: Verify Product = TRUE
Once this was done, the client application was restarted to take effect of the preferences. Afterwards, customer is finally able to click <Verify> button such that the workflow process executed successfully and set the Commit Time on the service request record accordingly.
Search keywords: workflow, process, FS - Verify Entitlement SR, verify, button, commit time, commit, service request, agreement, entitlement, response time, metric, priority, Method Invoked, VerifyEntitlement, PickRecord, Service Request Detail Applet, Service Entitlement Pick Applet, resume
Applies to:
Product Release: V7 (Enterprise)Version: 7.8.2.1 [19216]
Database: Oracle 9.2.0.2
Application Server OS: Microsoft Windows 2000 Server
Database Server OS: Microsoft Windows 2000 Server
This document was previously published as Siebel SR 38-3050160807.
Symptoms
SBL-BPR-00256We upgraded to 7.8 and the eservice registration workflow has the following error:
We
detected an Error which may have occurred for one or more of the following
reasons:
This operation cannot be completed. This operation is associated with an
interactive workflow, which has already run to completion and can no longer be resumed from this
operation. If the purpose of this operation is simply to take you to a view, you should be able
to reach the same view by using the "Forward/Backward" button of your browser or the Siebel
History panel. Otherwise, you need to restart the interactive flow from the beginning. For
example, if this operation is a step in a series of user-driven tasks, you need to restart from
the first task in the series.(SBL-BPR-00256)
This occured right after clicking "I Agree"
on the Usage Terms step of the workflow. Please help to troubleshoot this issue.
Solution
Message 1
For the benefit of other readers:The error message returned to the UI about "operation is associated with an interactive workflow, which has already run to completion and can no longer be resumed from this operation" usually occurs when there is a runtime event which is trying to invoke a workflow process instance which the workflow process instance has already completed. Ie, the workflow instance is no longer in a waiting or suspended status anymore.
The sql leading up to the error message from customer's log file is the following:
....
EventContext EvtCtxApplet 4 0 2006-06-16 03:32:39 User Registration Legal Confirmation Applet (FrameEventMethodAccept)
ObjMgrBusServiceLog InvokeMethod 4 0 2006-06-16 03:32:39 Begin: Business Service 'Workflow Process Manager' invoke method: 'ResumeProcess' at ab9bbb0
EngInv EngInv 3 0 2006-06-16 03:32:39 Workflow engine requested to perform method 'ResumeProcess'.
EngInv Arg 4 0 2006-06-16 03:32:39 Input: @0*0*5*0*0*0*7*EventId8*1-13ULF59*ProcessId8*1-198Y8S9*Sub Event22*FrameEventMethodAccept10*Event Name12*InvokeMethod6*StepId8*1-198X94
....
ObjMgrSqlLog Detail 4 0 2006-06-16 03:32:39 SELECT statement with ID: B15BC50
SELECT /*+ ALL_ROWS */
FROM
SIEBEL.S_WFA_INSTANCE T1
WHERE
(T1.STATUS_CD IN ( :1 ) AND T1.DEFINITION_ID = :2 AND T1.WORKITEM_ID = :3)
ObjMgrSqlLog Detail 4 0 2006-06-16 03:32:39 Bind variable 1: WAITING
[1/8]
Message 2
[2/8]ObjMgrSqlLog Detail 4 0 2006-06-16 03:32:39 Bind variable 2: 1-198Y8S
ObjMgrSqlLog Detail 4 0 2006-06-16 03:32:39 Bind variable 3: 1+1DU+214
ObjMgrSqlLog Debug 5 0 2006-06-16 03:32:39 User search spec: [Status Code] = "Waiting" AND [Definition Id] = "1-198Y8S" AND [Workitem Id] = "1+1DU+214"
....
ObjMgrSqlLog Detail 4 0 2006-06-16 03:32:39 SELECT statement with ID: B15BC50
SELECT /*+ ALL_ROWS */
FROM
SIEBEL.S_WFA_INSTANCE T1
WHERE
(T1.STATUS_CD IN ( :1 ) AND T1.DEFINITION_ID = :2 AND T1.WORKITEM_ID = :3)
ObjMgrSqlLog Detail 4 0 2006-06-16 03:32:39 Bind variable 1: SUSPENDED
ObjMgrSqlLog Detail 4 0 2006-06-16 03:32:39 Bind variable 2: 1-198Y8S
ObjMgrSqlLog Detail 4 0 2006-06-16 03:32:39 Bind variable 3: 1+1DU+214
ObjMgrSqlLog Debug 5 0 2006-06-16 03:32:39 User search spec: [Status Code] = "Suspended" AND [Definition Id] = "1-198Y8S" AND [Workitem Id] = "1+1DU+214"
.....
ObjMgrLog Error 1 0 2006-06-16 03:32:39 (procinst.cpp (206)) SBL-BPR-00125: Cannot resume process '1-198Y8S' for object '1+1DU+214'. Verify that an instance does exist and that it has a 'Waiting' or 'Suspended' status.
ObjMgrLog Error 1 0 2006-06-16 03:32:39 (engine.cpp (4791)) SBL-BPR-00256: This operation cannot be completed. This operation is associated with an interactive workflow, which has already run to completion and can no longer be resumed from this operation. ....
..
Message 3
[3/8]=======================================
Technical Support set up User Registration on SIA 7.8.2 using the standard out-of-the-box SRF and vanilla workflows, but could not reproduce the above error message or scenario.
Upon examining the customer's log file for the executed steps before the error, the last steps executed were the call to the subprocess 'User Registration SubProcess' workflow, which accepts inputs and returns outputs, and then the 'User Registration Legal Confirmation View' user interact step.
One thing that the 'User Registration SubProcess' workflow does is that displays the 'User Registration Initial Form Applet' to accept user entered data and then when the user clicks the next button, data is written causing a WriteRecord to fire off and a ROW_ID to get generated, in the customer's log file, this is row-Id value '1+1DU+214' (which is the one that the workflow could not resume on as indicated in the error/log sequence above). This rowid then gets saved into the 'Siebel Operation Object Id' of the subprocess and written also to the subprocess' Object Id through the 'Copy Object Id' step.
......
Message 4
[4/8]Then, when the subprocess is done, in vanilla version, this new Object Id value is to be passed back to the main workflow as a subprocess Output Argument. However, in the customer's version of the subprocess' Output Argument applet, 'Object Id' was not being returned to the main 'User Registration Process'. Thus, the main workflow process is not aware of the data/row created by the subprocess.
This is the entry in the vanilla version of the 'User Registration Process' workflow > 'Registration SubProcess' step > Output Argument list applet, in vanilla > Subprocess Output list applet:
Process Property Type Subprocess Output
---------------- -------- ------------------
Object Id Output Argument Siebel Operation Object Id
This entry is missing in output arguments applet of the customer's version of 'User Registration Process' workflow.
The solution was for customer to review their 'User Registration Process' workflow > 'Registration SubProcess' step > Output Argument list applet > add the above entry for 'Object Id' in this step. Then, deploy/activate the workflow process and restart the object manager. Once this change was performed, the error no longer occurs and the User Registration process/workflow was able to execute from start to finish.
.....
Message 5
[5/8]=======================================
Here is a more detailed explanation of how the above missing step caused the workflow resumption to fail in this particular issue:
"This operation cannot be completed. This operation is associated with an interactive workflow, which has already run to completion and can no longer be resumed from this operation."
... typically occurs when a workflow can not be resumed after it went into a wait state as a result of using a User Interact step and having a runtime event coming out of the User Interact step.
However, the issue itself is really another scenario of workflow failing to resume from a runtime event. In this case, the runtime event happens to be a button on an applet displayed in a view, where the view itself is displayed by the workflow's User Interact step. The Object Id received by the Object Manager for resuming the workflow did not match the Object Id that the waiting workflow is tied to.
1. First, the "User Registration Process" workflow initially ran and had no value for Object Id process property, it was null since no data was created.
......
Message 6
[6/8]2. Then, it went into the subprocess. The "User Registration Subprocess" executed, after the 'User Registration Form 1' step, a WriteRecord event occurred (due to user supplying data and clicking Next button). The WriteRecord event was on 'User Registration Initial Form Applet' which is based on the "User Registration" business component, so a row was written to this BC and the RowId was '1+1DU+214'.
3. Then, the subprocess ended and returned to it's caller workflow "User Registration Process". Back in the "User Registration Process" workflow, the Object Id remained null (since problematic version of this workflow did not receive the Object Id value from the subprocess output argument).
4. When the main workflow got control after the subprocess, it went into the "User Registration Legal Confirmation View" which is a User Interact step with a runtime event branch coming out of it - thus it would have to wait here for the runtime event to occur. Since there is a runtime event after this step, the workflow goes into a waiting/suspended state. As there is no explicit persistence set on this workflow, the workflow is persisted in memory, not in the database tables. At this point, the workflow is waiting to be resumed and the waiting instance has Object Id is null.
.....
Message 7
[7/8]5a. Next, when the user is at the "User Registration Legal Confirmation View" which is based on 'User Registration' busobject (primary bc is also 'User Registration') > on applet = "User Registration Legal Confirmation Applet" and clicking the button, this triggered off a runtime event and the runtime event is to resume the "User Registration Process" workflow. When a runtime event occurs, the object manager picks up the ROW_ID of the record from the primary business component of the view which the business object is based on.
5b. Since the view is based on 'User Registration' BO with primary BC 'User Registartion', it picked up the ROW_ID = '1+1DU+214' as this is the row created into this bc within this registration session and is also the row in context for this view based on the BC that the event occurred on. Thus, using this primary bc ROW_ID = '1+1DU+214', the object manager tried to resume the corresponding workflow with it. As part of the workflow's resumption mechanism, it checks to see if there is waiting/suspended instance for 'User Registration Process' workflow with Work Item Id (Object Id) = '1+1DU+214'. Since the waiting/suspended instance persisted with Object Id NULL but the work item passed in for resumption is '1+1DU+214', thus no waiting instance was found having Object Id = '1+1DU+214', so the workflow could not resume successfully, thus producing the error.
Thank you,
Oracle | Siebel Support
Message 8
[8/8]Search keywords: User Registration, workflow, process, error, failure, fail, resumption, This operation cannot be completed. This operation is associated with an interactive workflow, which has already run to completion and can no longer be resumed from this operation., SBL-BPR-00256, button, click, runtime event, resume, I Agree, user interact step, User Registration Legal Confirmation Applet, FrameEventMethodAccept, User Registration Legal Confirmation View, Object Id, NULL, S_WFA_INSTANCE, waiting, suspended, SBL-BPR-00125: Cannot resume process, Verify that an instance does exist and that it has a 'Waiting' or 'Suspended' status, SBL-BPR-00256
.
Applies to:
Siebel Workflow - Version: 8.0 SIA [20405] - Release: V8Information in this document applies to any platform.
Symptoms
During user registration, the registration screen does not resume the next page after clicking Next button. The object manager log show the error :
ObjMgrLog Error 1 000000114b8b0230:0 2010-03-01 06:52:34 (procinst.cpp (243)) SBL-BPR-00125: Cannot resume process '1-CN7' for object 'VRId-0'. Verify that an instance does exist and that it has a 'Waiting' or 'Suspended' status.
Setup :
- Create a custom Bs to invoke the "User Registration Process" with Workflow Process Manager BS, RunProcess Method. Compile this BS.
- Goto Runtime Event. Query the Applet : Login Applet
- Drill down the Acton with for record with event : FrameEventMethodRegisterNewUser
- In Action, uncheck the Active field.
- Create a new Action. Enter the Business service and business service method as compiled earlier on.
- Click on the Reload Runtime event in the menu.
Reprod steps :
- Launch the eService_enu apps.
- At the login page, click New User.
- Enter the Basic info and click next.
Expected behavior : the screen should move to the Address input view.
Actual behavior : The basic info view remains. No change.
Cause
CR# 10587771 - Can not Resume Interactive Workflow After Upgrade to SIA 8.0.0.8 has been logged to address this problem.Solution
Customer resolved the problem by upgrading to the SIA 8.0.0.9 instead. The problem is resolved in this version.References
BUG:10587771 - CAN NOT RESUME INTERACTIVE WORKFLOW AFTER UPGRADE TO SIA 8.0.0.8Applies to:
Product Release: V7 (Professional)Version: 7.7.2.2 [18356]
Database: Oracle 9i
Application Server OS: Microsoft Windows 2000 Server SP 4
Database Server OS: Microsoft Windows 2000 Server SP 4
This document was previously published as Siebel SR 38-3008152701.
Symptoms
SBL-UIF-00401, SBL-SCR-00141, SBL-DAT-00215, SBL-DAT-00712, SBL-SVR-01051, SBL-SCM-00022, SBL-SMI-00033, SBL-NET-01023, SBL-BPR-00125, SBL-BPR-00151Hi,
We are having problems using drag drop functionality on SWE. When you try to save the
attached document systems gives the error "Session Warning: The server you are trying to access
is either busy or experiencing difficulties. Please close the Web browser, open a new browser
window, and try logging in again." and logs out the user. We have tried the same functionality
with dedicated client and it works ok. We also tried the functionality with DB authentication on
SWE and had the same error. We are currently using ADSI authentication for production.
The
best I have found from SWE logs is as
follows.
ProcessPluginRequest ProcessPluginRequestError 1 0 2006-04-18
17:15:22 5116: [SWSE] RPC coming in without a user
session
ProcessPluginRequest ProcessPluginRequestError 1 0 2006-04-18
17:15:22 5116: [SWSE] Failed to obtain a session ID. NOT
OK
ProcessPluginRequest ProcessPluginRequestError 1 0 2006-04-18
17:15:22 5116: [SWSE] Set Error Response (Session: Error: 00065535
Message: NOT OK)
Your help is appreciated.
Solution
Message 1
For the benefit of other readers,Customer reported that drag drop attachment functionality on SWE (Web Client) is not working. Further, the following error message was reported while saving the drag & drop attachments from the windows explorer.
"Session Warning: The server you are trying to access is either busy or experiencing difficulties. Please close the Web browser, open a new browser window, and try logging in again." and finally logs out the user.
Comments:
Initial investigation steps included the following checks and confirmation from the customer:-
- This behavior was happening on all attachment screens.
- Drag & drop attachments from the windows explorer onto the “Siebel Application > Attachments Screen” works fine on a Siebel dedicated client. However, the same functionality is not working for the SWE _Web Client, for all the USERS.
- Even tried attaching a small size file, this did not work either (just to eliminate the size and type of document they were attaching).
Next, we noticed few error messages like
**********************************
ObjMgrLog Error 1 0 2006-05-09 10:05:26 (init.cpp (232)) SBL-SCR-00141: Siebel eScript runtimefout in procedure 'GetFieldValue' van BusComp [DHB Financial Accounts]:
Error: SiebelError: Deze bewerking is niet toegestaan wanneer geen records worden weergegeven. Voer eerst een query uit die minstens één record retourneert of voeg een nieuwe record toe.(SBL-DAT-00215)
<CONT'D> Resolution 1 of 2........
Message 2
<CONT'D> Resolution 2 of 2........ObjMgrLog Error 1 0 2006-05-09 10:05:26 (init.cpp (232)) SBL-SCR-00141: Siebel eScript runtimefout in procedure 'GetFieldValue' van BusComp [DHB Financial Accounts]:*****
********************************
So just to eliminate the possibility of eScript related issue, customer conducted testing by setting "EnableScripting" parameter false and later also setting Application Object parameter "Application Scripting Enabled" to false. However, still the behavior was the same.
Finally, customer confirmed that the root cause of this reported issue was to do with the underscore "_" character which was used for naming their Servers. Basically, the server network name of their production server was "SIEBEL_PROD". That problem occurs because of that underscore "_" character. So when they used the IP address of the actual server instead of the server name (with underscore ‘_’) everything started working as expected.
Additional reference to similar issues which are posted on Support web:
"Service Request #: 38-2936429161 - problem to upload attachment bigger than 1 MG"
Document Enhancement Request 12-IYK4BR has been logged to make sure that this is documented in Siebel Bookshelf.
"Alert 1067: Siebel Server Failures Due to Hyphen Character in Machine Hostname and in the Siebel Server Name"
Thank You,
Siebel Technical Support
Applies to:
Product Release: V7 (Enterprise)Version: 7.5.3.2 [16168] Fin Svcs
Database: Oracle 9.2.0.4
Application Server OS: Sun Solaris 8
Database Server OS: Sun Solaris 8
This document was previously published as Siebel SR 38-1580926721.
Symptoms
SBL-BPR-00125Hello,
When I click on my Finalize button (in for example the IPO-workflow), or the abort
button, I get the error: "Cannot Resume process ..."
The Row-id that is mentioned in this
message corresponds to an other workflow that is not launched during the complete process (for
example Foreign Market workflow).
I have already made a revise of all the workflows,
deleted the active versions of these workflows, deleted all the runtime events regarding those
workflows, did a reload personalisation, activated the workflows, did a reload
personalization.
This doesn't seem to help.
before I did this, the foreign market
workflow worked, belgian market didn't work. after these actions it was vice versa. other
workwlows that didn't work and pointed to the foreign market workflow haven't changed, they still
point to the foreign market workflow.
to make the problem even harder to find: sometimes a
workflow works, sometimes it doesn't.
In my case I pass from the generic workflow to the
run market workflow to the (ex) IPO workflow
When clicking on the finalize or abort button in
the IPO workflow, the "cannot resume ..." message is shown, but the IPO workflow ends, returns to
the run market, returns to the generic, creates an history record and stops before the workflow
navigates me to a contact view.
the generic workflow and the sub-process for the navigating
are exaclty the same in beta as in gamma.
I really don't know where to search
anymore.
In alpha and beta everything worked just fine.
I've added a zip file that
contains all the XML files of the workflows.
If you need any more information: just let me
know
Yours truely,
Youri
Solution
Message 1
For the benefit of other readers, the following problem was encountered.There are several workflow processes having a user interact step navigating to the same view and waiting for the same Runtime event (RTE) from the same applet to resume. In such context, the error below occurs for one of the process.
Cannot resume process '%1' for object '%2'. Verify that an instance does exist and that it has a 'Waiting' (SBL-BPR-00125)
For instance, assume processes P1 and P2 having a user interact and resuming on event E1.
A user does the following within the application.
1. User starts P1, user interact step is reached.
2. User triggers event E1, P1 resumes and finishes.
3. User starts P2, user interact step is reached.
4. User triggers event E1, P2 resumes and finishes.
5. User starts P1 again, user interact step is reached.
6. User triggers event E1, P1 resumes but the error above occurs, where process referenced is P2.
Change request #12-SNVJP6 was created for this product defect.
In the above example, the RTE resuming the processes was defined as below.
Object Type: Applet
Object Name: <myApplet_name>
Event: InvokeMethod
Subevent: <myCustomMethod>
Continue ...
Message 2
... Part 2The following workaround solved the problem in this case. It consists to change the RTE to buscomp “PreInvokeMethod” event instead of applet “InvokeMethod”. For instance, from the above RTE definition, change to the following.
Object Type: BusComp
Object Name: <buscomp behind myApplet_name>
Event: PreInvokeMethod
Subevent: <myCustomMethod>
Jérôme Patard, Siebel Technical Support.
No comments:
Post a Comment