SBL-SRB-00047: Could not route message

Applies to:

Siebel Workflow - Version: 7.7.2.5 [18368] to 8.1.1 [21112] - Release: V7 to V8
Information in this document applies to any platform.
This document was previously published as Siebel SR 38-3070028991.

Symptoms

Customer has several custom workflow monitor agent components created. These work fine until the last few days where the agents fail with the following logs:
SrmLayerLog    Error    1    0    2006-06-19 16:51:28    (srbroute.cpp(2052) err=5700035 sys=0) no other server

SrmLayerLog    Error    1    0    2006-06-19 16:51:28    (srbmsgfn.cpp(387) err=5700047 sys=0) Could not route message to WfProcMgr with registered key (null)

GenericLog    GenericError    1    0    2006-06-19 16:51:28    (srmconn.cpp (3049) err=5700047 sys=126) SBL-SRB-00047: Could not route message to WfProcMgr with registered key (null)

GenericLog    GenericError    1    0    2006-06-19 16:51:28    (srmconn.cpp (2703) err=5700047 sys=0) SBL-SRB-00047: Could not route message to WfProcMgr with registered key (null)

GenericLog    GenericError    1    0    2006-06-19 16:51:28    (srmconn.cpp (2303) err=5700047 sys=0) SBL-SRB-00047: Could not route message to WfProcMgr with registered key (null)

Cause

The workmon is not able to communicate to wfprocmgr because this component is currently unavailable.

Solution

After Reviewing  Siebns.dat, it was observed that the wfprocmgr had a status of Offline a for the particular server. When a component is in a Offline status, it is not automatically started when the Siebel Server is bounced.

Following steps to set the component online that helped resolve the issue :

(1) Navigate to the Administration - Server Management > Enterprise. In this view, select the appropriate enterprise on the first applet (Enterprise). On the same view for the second applet (Server) select the appropriate server. On the same view again for the third applet (Component) select the appropriate component (wfprocmgr).

(2) Then click the 'Startup' button. Refresh the list applet and again for the same component you need to click 'Online' button. Each time you click the button you need to give it a minute for the compont to startup or online but keep trying this until you see the component is 'Online'.

(3) Navigate to the Administration - Server Configuration > Enterprises > Synchronization, to synchronize your batch components.

It is also suggested can create a new custom workmon, You can refer following document.

How Do You Start a Workflow Monitor Agent in Siebel Version 7.x? (Doc ID 476425.1)

This document directs that how to create a new component , but it is always recommended making a copy of the vanilla workmon component and then setting the new component names according to the above document. The workmon component parameters should be set as per following.

Group Name <name of policy group>
Default Tasks=1
Max Tasks = 1

Applies to:

Siebel System Software - Version 7.5.1 SIA [15026] to 8.1.1.8 SIA [23012] [Release V7 to V8]
Information in this document applies to any platform.
Version:Siebel 7.5/7.7.x/ 7.8.x and Siebel 8.1and later

Purpose

This document is intended to provide cause and corrective action information about Siebel Error Message SBL-SRB-00047: Could not route message to %1 with registered key %2.

Scope

This document is informational and intended for any user.

Details

Explanation

Possible causes are 1) SRB is not ready to accept messages from SRProc if this message is in the SRProc log file, or 2) The component to be notified may not be running if this exists in the SRB log file.

Corrective Action

Check to make sure that: 1) SRB is running, 2) The components that sent the request are still running to accept notifications.

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 Territory Management - Version 8.0.0.3 SIA [20416] and later
Information in this document applies to any platform.

Symptoms

Attempted to run a simple Major Alignment after setting up Territory Management in Dev environment. I had to apply the Configuration Instructions for FR 12-1GCZKV9. I'm now seeing the following error on step 'Remove Assignment Results' possibly due to the datatype (string) of the property 'Alignment Id':

StpExec End 4 0000000b4fab1f48:43958 2012-05-10 11:18:47 Stopping step instance of 'Post TOS Process' with a 'Completed' status.
StpExec Create 4 0000000b4fab1f48:43958 2012-05-10 11:18:47 Instantiating step definition 'Remove Assignment Results'.
PrcExec PropSet 4 0000000b4fab1f48:43958 2012-05-10 11:18:47 Getting runtime value of property 'Namespace: 'USER' Name: 'Alignment Id' Datatype: 'String''.
StpExec Task 4 0000000b4fab1f48:43958 2012-05-10 11:18:47 Invoking method 'Remove Assignment Results' on business service 'Alignment Management Service'.
StpExec TaskArg 4 0000000b4fab1f48:43958 2012-05-10 11:18:47 Input: @0*0*1*0*0*0*12*Alignment Id7*1-QAV7R
SrmLayerLog Error 1 0000000b4fab1f48:43958 2012-05-10 11:18:47 (srbroute.cpp(2130) err=3735555 sys=0) Cannot find the entry in routing table.
SrmLayerLog Error 1 0000000b4fab1f48:43958 2012-05-10 11:18:47 (srbmsgfn.cpp(389) err=3735599 sys=0) Could not route message to RTIBatch with registered key (null)
GenericLog GenericError 1 0000000b4fab1f48:43958 2012-05-10 11:18:47 (srmconn.cpp (3090) err=3735599 sys=0) SBL-SRB-00047: Could not route message to RTIBatch with registered key (null)
GenericLog GenericError 1 0000000b4fab1f48:43958 2012-05-10 11:18:47 (srmconn.cpp (2744) err=3735599 sys=0) SBL-SRB-00047: Could not route message to RTIBatch with registered key (null)
GenericLog GenericError 1 0000000b4fab1f48:43958 2012-05-10 11:18:47 (srmconn.cpp (2321) err=3735599 sys=0) SBL-SRB-00047: Could not route message to RTIBatch with registered key (null)
ObjMgrLog Error 1 0000000b4fab1f48:43958 2012-05-10 11:18:47 (stepexec.cpp (1540)) SBL-BPR-00162: Error invoking service 'Alignment Management Service', method 'Remove Assignment Results' at step 'Remove Assignment Results'.

Is this a known issue?

Cause

The error could not route can mean the 'RTI Batch' (RITBatch) component is not available. First you need to check if the RTIBatch is online in Administration - Server Management > Servers > Component Groups, there should be a component group named "Siebel RTI" which has only one component named 'RTI Batch".

In this case, the RTIBatch component was not enabled, the request could not be routed to it thus failed with the error.

Solution

Customer enabled the component group "Siebel RTI", Synchronize the components, and restart Siebel Server service.   This resolved the error.

The revelent documentation is in the following Bookshelf:

Siebel Territory Management Guide > Setting Up Siebel Territory Management > Process of Setting Up Siebel Territory Management

Siebel Territory Management Guide > Setting Up Siebel Territory Management > Process of Setting Up Siebel Territory Management >
Enabling Component Groups for Siebel Territory Management

Applies to:

Siebel Scheduling - Version: 8.1.1.5 [21229] and later   [Release: V8 and later ]
Information in this document applies to any platform.

Symptoms

====Issue Clarification====
When attempting to book Appointment ,
the following error occurs.

ERROR
-----------------------
Siebel
---------------------------
SrmLayerLog Error 1 0002078c4ecb02d3:0 2011-11-24 14:25:42 (smiworkq.cpp(1577) err=1376472 sys=0) Internal: Not an error, all the threads are busy

SrmLayerLog Error 1 0002078c4ecb02d3:0 2011-11-24 14:25:42 (srbroute.cpp(2148) err=3735587 sys=0) No server available to service this request.

SrmLayerLog Error 1 0002078c4ecb02d3:0 2011-11-24 14:25:42 (srbmsgfn.cpp(389) err=3735599 sys=0) Could not route message to ApptBook with registered key 1-NZU2ZD.

GenericLog GenericError 1 0002078c4ecb02d3:0 2011-11-24 14:25:42 (srmconn.cpp (3090) err=3735599 sys=0) SBL-SRB-00047: Could not route message to ApptBook with registered key 1-NZU2ZD.

GenericLog GenericError 1 0002078c4ecb02d3:0 2011-11-24 14:25:42 (srmconn.cpp (2744) err=3735599 sys=0) SBL-SRB-00047: Could not route message to ApptBook with registered key 1-NZU2ZD.

GenericLog GenericError 1 0002078c4ecb02d3:0 2011-11-24 14:25:42 (srmconn.cpp (2321) err=3735599 sys=0) SBL-SRB-00047: Could not route message to ApptBook with registered key 1-NZU2ZD.

ObjMgrBusServiceLog InvokeMethod 4 0002078c4ecb02d3:0 2011-11-24 14:25:42 Business Service 'Server Requests' invoke method 'SubmitRequest' Execute Time: 0.058 seconds.

ObjMgrBusServiceLog InvokeMethod 4 0002078c4ecb02d3:0 2011-11-24 14:25:42 End: Business Service 'Server Requests' invoke method: 'SubmitRequest' at 174303b8

ObjMgrBusCompLog Error 1 0002078c4ecb02d3:0 2011-11-24 14:25:42 (basesch.cpp (475)) SBL-DAT-00472: Generic SSA NOTOK error message.


STEPS
-----------------------
Check of the ApptBook job. If it’s queued status – restart the Siebel Server

- Create an activity with the same plan start/ end, earliest start and end dt. goto Schedule view. Unlock the assignment and associated to the service region define above.

- Click the Book Appt button.

- system popup message : Generic SSA NOTOK error message

- goto administration - User. Select an employee and associate the schedule and service region to him

- Goto Administration - Scheduling. Click Load ABS.

- Go back to the Activity. Click the Book Appt.

The same problem persists.

Cause

The upgrade process caused the truncation of the S_SRM_ACTION table. This results in the system unable to route the request to the ApptBook component.

Due to the missing data in S_SRM_ACTION table, the Server Key Mapping on the UI is incomplete.

Solution

Complete the data entry in the Server Key Mapping view. Customer resolved the error after performing this.

Note : to help diagnose the problem, customer were asked to run the following syntax at Siebel Server commandline :

run task for comp ApptBook with method='ReloadServiceRegion',SvcRegnId='1-REU0NA'
run task for comp ApptBook with method='Getappointment',SvcRegnId='1-REU0NA',ActId='1-242U83N'

Trace the apptbook log to verify if the above runs without error. If no error exists, do review the setup like Server Key Mapping, the availability of SRBroker.

Applies to:

Siebel System Software - Version 7.7.2.6 SIA [18372] to 8.1.1.8 [23012] [Release V7 to V8]
Oracle Solaris on SPARC (64-bit)
Product Release: V7 (Enterprise)
Version: 7.7.2.6 [18372] Life Sci
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-3307344231.

""""Checked for relevance on 28-Apr-2010""""
"Checked for relevance on 11-Oct-2012"

Symptoms

SBL-UIF-00230, SBL-SRB-00047, SBL-NET-01020
We are not able to generate correspondence from our document server (which runs on a Win2000 SP 4) box. The actual siebel server and gateway runs on a solaris box. We are not seeing siebel.html being generated in the \reports folder of the doc server. I have added all the files from the log folder of this .doc server including a .saf which the log says does not exist in the file system. Please assign some body as soon as possible as we are not seeing this issue in any other environments, but the testers are waiting to test this particular functionality.

Thanks

Cause

Solution

Message 1

For the benefit of other readers:

Correspondence requests for the Document Server were failing as it was not able to reach templates stored in the File System. Further review of Siebel log files uncovered the following errors:

** From DocServer log files:

SBL-SRB-00047: Could not route message to FSMSrvr with registered key (null)
SBL-UIF-00230: The file 'Shipment Confirmation.doc' could not be found on any specified file system.

** From SRBroker log file:

SBL-NET-01020: Internal: unknown hostname

The customer implemented Siebel File System on a Unix box where another Siebel server was installed. When the template file is requested by Document Server, this requisition goes through SRBroker component to be routed to a File System Manager instance. Since the local File System Manager is disabled – and this is the correct configuration for heterogeneous environments –, SRBroker will try to route it to the active File System Manager running on Unix server. As the Unix hostname cannot be resolved on the Document Server machine, the request fails and the merge process is aborted.

The issue was resolved after fixing the DNS settings on the Document Server machine to correctly resolve the Unix hostname.