SBL-SRB-00032

Applies to:

Siebel Workflow - Version: 7.7.2.4 SIA [18365] and later   [Release: V7 and later ]
IBM AIX on POWER Systems (64-bit)
Product Release: V7 (Enterprise)
Version: 7.7.2.4 [18365] Auto
Database: Oracle 9.2.0.7
Application Server OS: IBM AIX 5L 5.2
Database Server OS: IBM AIX 5L 5.2

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

Symptoms

We are trying to Integrate QAS with Siebel, and are experienceing some difficulties.

We have a picklist that uses a virtual Business component which is populated with data from the PAF file via the QAS DLLs.

The script calls a workflow process located on the windows server, but seems to fail each time and outputs a msg to our error handling tables:

Error: SiebelError: Could not route message to NWfProcMgr with registered key (null)
no more remote SRB instance
Error near no filename:189 [InvokeMethod()].
      from no filename:189 [Query()]
      from no filename:283 [Service_PreInvokeMethod()]
     
Error: SiebelError: Could not route message to NWfProcMgr with registered key (null)
Cannot open asynchronous SISNAPI connection.
Internal: unknown hostname
Error near no filename:189 [InvokeMethod()].
      from no filename:189 [Query()]
      from no filename:283 [Service_PreInvokeMethod()]     
     
The error is reported from the attached scripts - The preinvoke method script calls the query fucntion.

Within the Query function a call is made to run a named process via the named process manager, and this is where it is falling over.
A server request for a custom wfprocmgr component on a separate (Windows) server was being made from a unix machine.

It was confirmed that the custom wfprocmgr component was online on the Windows server, the components had been synchronized, and the Siebel Servers had been re-started.

Cause

The cause of the error was found to be that the unix server did not have host name of target server in the /etc/hosts file.

Solution

After adding the required entry to this file on the unix server, the problem was resolved.

Applies to:

Siebel Workflow - Version: 7.5.2.100 [15252] and later   [Release: V7 and later ]
z*OBSOLETE: Microsoft Windows 2000
Product Release: V7 (Enterprise)
Version: 7.5.2.100 [15252]
Database: Oracle 8.1.7.4
Application Server OS: Microsoft Windows 2000 Server SP 2
Database Server OS: Microsoft Windows 2000 Server SP 2

””Checked for Relevance on 11-01-2012””

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

Symptoms

SBL-OMS-00203, SBL-SRB-00047, SBL-SRB-00032We created a workflow process that invokes Assignment Manager using the Synchronous Assignment Manager Requests business service.

We had to restart the Siebel Services this morning and, after we did, the FJS Assignment
Monitor failed when trying to run the assignment for a contact.   I've attached the log file for the failing Workflow task.    It seems to be following the correct, new Workflow Process but failing when trying to call the Assignment task.  

The Assignment Manager task is still running.

I'd be grateful if you take a quick look at the log file and advise.

Cause

Expected behavior

Solution

Message 1

For the benefit of other users, the customer had a Workflow Monitor Agent (WMA) that invoked a workflow process which, in turn, invoked Assignment Manager (AM). The WMA was configured so that a task was started automatically when the component was started. When the siebel server was stopped and started a Workflow Process Manager (WPM) task failed with the following error:

Object manager error: ([0] AsgnSrvr with key [(null)] is not available (0x7031)) Object manager error: ([1] no more remote SRB instance (0x7031)) Object manager error: ([2] Error invoking service 'Synchronous Assignment Manager Requests', method 'Assign' at step 'Business Service'. (0x813f))
When the WMA was started again the same request was correctly processed. This strongly suggested that the reported behavior occurred because the WPM had submitted the request before AM had come up after the Siebel Server was restarted.

Change request 12-JMAGIJ has been raised to look into the reported behavior and consider implementing some sort of solution. For example, users could be given the ability to specify dependencies between components and as a result the application could start up components that are invoked by other components first. Please note that all requests are reviewed and prioritized for possible inclusion in a future release.

Continued in next entry.

Message 2

Continued from previous entry.

Using the Number of Restarts and Minimum Up Time parameters for the WMA the customer addressed the behavior by configuring the application so that if the WMA task fails another task will be automatically started until AM starts up and can process the request from the WPM.

For more information on these parameters please refer to Technical Note 259: [Component Automatic Restart & Component Database Error Recoverability] on SupportWeb. For more information on this possible solution please refer to Service Request #: 38-895759251 [Workflow/Assignment Manager Failures - Production Issue].