Applies to: Siebel System Software - Version: 7.8.2 SIA [19213] and later [Release: V7 and later ]
z*OBSOLETE: Microsoft Windows Server 2003
Product Release: V7 (Enterprise)
Version: 7.8.2 [19213] Com/Med
Database: Microsoft SQL Server 2000 SP3
Application Server OS: Microsoft Windows 2003 Server
Database Server OS: Microsoft Windows 2003 Server
This document was previously published as Siebel SR 38-2749871082.
***Checked for relevance on 18-Nov-2010***
SymptomsWhile accessing a queue on JMS server with authentication and authorization enabled through JMS Receiver server component in Siebel 7.8.2, the required username and password to perform a JNDI look up were specified in jndi.properties file with the parameters:
java.naming.security.principal=<username>
java.naming.security.credentials=<password>
The required username and password to perform to create connections to the JMS server were specified in named subsystem of type JMSSubsys with the parameters:
ConnectionUsername
ConnectionPassword
However, the following error was caused when the JMS Receiver component attempted to make connection to the queue:
A JMS exception occurred in EAI JMS Transport: 'Exception: javax.jms.JMSSecurityException: invalid name or password; Message: invalid name or password'.(SBL-EAI-05103)
CauseIncorrect jar files were used.
Siebel Technical Support followed the same steps to provide the required username and password in jndi.properties and named subsystem but could not reproduce the same behavior in Standard Siebel 7.8.2 environment and the connection to the JMS server was created successfully. Thus, JVM log files generated in customer and Siebel Technical Support environment were compared and it was found that the following traces did not appear in JVM log from customer environment:
1:51:29.009 PM Wed Jan 4: >ConnectionFactory=QueueConnectionFactory
1:51:29.009 PM Wed Jan 4: >ConnectionUsername=siebel
1:51:29.009 PM Wed Jan 4: >ConnectionPassword=*
1:51:29.009 PM Wed Jan 4: >SendUsername=
1:51:29.009 PM Wed Jan 4: >SendPassword=*
1:51:29.009 PM Wed Jan 4: >ReceiveQueue=TEST_A
1:51:29.009 PM Wed Jan 4: >ReceiveUsername=
1:51:29.009 PM Wed Jan 4: >ReceivePassword=*
1:51:29.009 PM Wed Jan 4: >TopicUsername=
It would mean that JMS Receiver component did not send any credentials (Username and Password) to destination JMS server in customer Siebel environment. As result, the JMS server could not authenticate the JMS Receiver and the reported error was caused, even if the parameters to pass the credentials were specified properly.
Through further research, it was found that Siebel JAR files “Siebel.jar†and “SiebelJI_enu.jar†used in customer environment were not same as the ones for Siebel 7.8.2.
SolutionMake sure you use the jar files from siebsrvr/classes directory from your siebel server installation.
ReferencesNOTE:850954.1 - Basic Troubleshooting Steps for EAI JMS Transport
NOTE:859382.1 - How to Control Parameters on Transport for Outbound Web Service, e.g. HTTPSleepTime (HTTP) or SendUsername (JMS)
NOTE:971592.1 - Connect to AIA from your Enterprise via JMS
NOTE:1077448.1 - How to set up Siebel JMS with Oracle AQ
NOTE:978645.1 - Websphere MQ Supported Versions For Siebel EAI MQ Series Server Transport / EAI JMS Transport
Applies to: Siebel CRM - Version: 8.1.1 SIA [21111] and later [Release: V8 and later ]
Information in this document applies to any platform.
SymptomsWhen trying to test a send message to AIA, the following error occured
----------------------------------------------------------
Error msgbox:
----------------------------------------------------------
A JMS exception occurred in EAI JMS Transport: 'Exception: oracle.jms.AQjmsException: Io exception: The Network Adapter could not establish the connection; Message: Io exception: The Network Adapter could not establish the connection'.(SBL-EAI-05103)
Cause
Comments
--------
The error was in AIA configuration (application.xml).
The access to AIA database was done with IP+port which SOA/AIA returned to Siebel. The retuned IP was wrong, since it pointed to the AIA application server, and not the database server.
Solution
Comments
--------
The error was in AIA configuration (application.xml).
You can discover this by checking the connections done by Siebel Server to AIA, with TCPView.
It connects to OC4J_SOA on port 6003, but after it opens 14204, and then also tries to connect to AIA database (in this case, port 1523).
The access to AIA database was done with IP+port which SOA/AIA returned to Siebel. The retuned IP was wrong, since it pointed to the AIA application server, and not the database server.
Applies to: Siebel CRM - Version: 8.0 [20405] to 8.1.1 [21112] - Release: V8 to V8
""""Checked for relevance on 29-OCT-2010""""
SymptomsJMS_EXCEPTION at impersonated (SecureWebService) Inbound WS call processed by JMS Received causes inconsistent behavior: message data are updated in Siebel Db, but message self rolled back into input JMS Queue.
The behavior appears in the following sequence:
1. The JMS Receiver is set to dispatch all received message by the "SecureWebService" named subsystem (EAI Data Handling profile);
2. External application puts a message with SOAP XML request into the JMS Queue. The SOAP Header of the request includes WS-Security fields with Siebel user credentials;
3. The JMS Receiver pick ups the SOAP XML message from the JMS Queue;
4. The JMS Receiver impersonates the user (changes its session context to the specified Siebel User), by the information from WS-Security fields in the SOAP Header;
5. The received SOAP Request is get dispatched to accordant Inbound Web Service implementation (a business service or a workflow process);
6. The Web Service implementation completes the processing (for example updates or/and queries Siebel Data)
7. The EAI Transaction commits the updates in Siebel Db.
8. The JMS Receiver fails to commit the message processing to the JMS Queue (to remove the message from the Queue), because of the raised "JMS_EXCEPTION" java error without detailed information.
9. As result the message stays in the JMS Queue and can be picked up by JMS Receiver again for processing, disregarding of successful completion it at previous run.
10. The Siebel Db is updated, while the JMS Messaging Provider does not receives positive sign to remove the processed message from the JMS Queue as "committed".
* * *
This behavior has been reproduced in 8.0.0.6 SIA and 8.1.1 SIA products and may affect other 8.x Release.
The traces appearing in the JMS Receiver log (8.0.0.6 [20423] ENU) were:
"...
ObjMgrBusServiceLogObjMgrBusServiceLog InvokeMethod 4 ... Begin: Business Service 'Web Service Inbound Dispatcher' invoke method: 'Dispatch' ...
...
WebSvcInboundWebSvcInbound WSInboundTrace 3 ... Envelope Processing
WebSvcInboundWebSvcInbound WSInboundTrace 3 ... Impersonate
...
WebSvcInboundWebSvcInbound WSInboundTrace 3 ... Executing web service operation '...' by calling ...
...
WebSvcInboundWebSvcInbound WSInboundTrace 3 ... Completed inbound web service execution.
...
ObjMgrBusServiceLogObjMgrBusServiceLog InvokeMethod 4 ... End: Business Service 'Web Service Inbound Dispatcher' invoke method: 'Dispatch' ...
EAITransport EAITransportGenericEAITransportGeneric 3 ... Dispatch Service: 'Web Service Inbound Dispatcher', Method: 'Dispatch' completed successfully
ObjMgrBusServiceLogObjMgrBusServiceLog InvokeMethod 4 ... Business Service 'EAI Transport Dispatch Service' invoke method 'GenericDispatch' ...
ObjMgrBusServiceLogObjMgrBusServiceLog InvokeMethod 4 ... End: Business Service 'EAI Transport Dispatch Service' invoke method: 'GenericDispatch' ...
ObjMgrBusServiceLogObjMgrBusServiceLog Delete 4 ... Business Service 'EAI Transport Dispatch Service' ... was unregsitered ...
ObjMgrBusServiceLogObjMgrBusServiceLog Delete 4 ... Business Service 'EAI Transport Dispatch Service' was deleted ...
ObjMgrSessionLogObjMgrSessionLog Warning 2 ... (physmod.cpp (4998)) SBL-DAT-00473: No transaction is in progress
ObjMgrBusServiceLogObjMgrBusServiceLog Create 4 ... Business Service 'EAI JMS Java Business Service Caller' was created ...
ObjMgrBusServiceLogObjMgrBusServiceLog Create 4 ... Business Service 'EAI JMS Java Business Service Caller' ... was regsitered ...
EAITransport EAITransportDebugEAITransportDebug 4 ... Invoking JMS Java method Commit
ObjMgrBusServiceLogObjMgrBusServiceLog InvokeMethod 4 ... Begin: Business Service 'EAI JMS Java Business Service Caller' invoke method: 'Commit' ...
...
EAITransport EAITransportDebugEAITransportDebug 4 ... Finished copying properties
EAITransport EAITransportDebugEAITransportDebug 4 ... Finished copying type
EAITransport EAITransportDebugEAITransportDebug 4 ... Finished copying value
EAITransport EAITransportDebugEAITransportDebug 4 ... End Creating instance of output property set
...
ObjMgrBusServiceLogObjMgrBusServiceLog Error 1 ... (javabsvc.cpp (181)) SBL-EAI-05000: Business Service call returned error code JMS_EXCEPTION and message: An unexpected error occurred (see StackTrace): null
ObjMgrBusServiceLogObjMgrBusServiceLog InvokeMethod 4 ... Business Service 'EAI JMS Java Business Service Caller' invoke method 'Commit' ...
ObjMgrBusServiceLogObjMgrBusServiceLog InvokeMethod 4 ... End: Business Service 'EAI JMS Java Business Service Caller' invoke method: 'Commit' ...
ObjMgrBusServiceLogObjMgrBusServiceLog Error 1 ... (jmsbsvc.cpp (323)) SBL-EAI-05103: A JMS exception occurred in EAI JMS Transport: 'An unexpected error occurred (see StackTrace): null'.
ObjMgrBusServiceLogObjMgrBusServiceLog InvokeMethod 4 ... Business Service 'EAI JMS Transport' invoke method 'ReceiveDispatch' ...
ObjMgrBusServiceLogObjMgrBusServiceLog InvokeMethod 4 ... End: Business Service 'EAI JMS Transport' invoke method: 'ReceiveDispatch' ...
..."
The SOAP XML Request was made like the example below:
<s:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" ...>
<s:Header>
<ws:Security xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/07/secext">
<ws:UsernameToken>
<ws:Username>...</ws:Username>
<ws:Password ..>...</ws:Password>
</ws:UsernameToken>
</ws:Security>
</s:Header>
<s:Body>...</s:Body>
</s:Envelope>
Cause
We presume, that user context change used in the impersonation approach at each incoming Web Service call caused reset of outstanding transaction flags.
Working without user context changing prevents occurrence of the behavior.
The Change Request BUG 10565450 has been logged to address this case.
Solution1. WORKAROUND, verified for Siebel 8.1.1 Release:
<s:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:s2="http://siebel.com/webservices" ...>
<s:Header>
<s2:UsernameToken>...</s2:UsernameToken>
<s2:PasswordText>...</s2:PasswordText>
<s2:SessionType>None</s2:SessionType> </s:Header>
<s:Body>...</s:Body>
</s:Envelope>
This workaround may not help in Siebel 8.0 Release.
2. WORKAROUND, verified for Siebel 8.0 and Siebel 8.1.1 Release:
Change the intgeration approach to not use impersonation feature for Inbound Web Service calls (SOAP XML requests), received and processed by the JMS Receiver task.
Using of the "WebService" EAI Data Handling subsystem will keep the integration working. The only side effect of this solution is that the context of the JMS Receiver user (specified in the component parameters) will be used for processing of all messages.
ReferencesBUG:10565450 - JMS_EXCEPTION AT 'COMMIT' OF 'EAI JMS JAVA BUSINESS SERVICE CALLER' FOR INBOUND WS WITH WSSE-AUTH.
NOTE:850954.1 - Basic Troubleshooting Steps for EAI JMS Transport
NOTE:1076251.1 - Master Note for Siebel Web Services
Applies to: Siebel CRM Call Center - Version: 8.1.1.3 SIA[21219] and later [Release: V8 and later ]
Information in this document applies to any platform.
SymptomsSIEBEL VERSION: 8.1.1.3
ISSUE STATEMENT:
JMS connections from Siebel to Oracle AQ are not working on the TEST environment while they work correctly on the DEV one.
ERROR:
7:06:51.853 AM Tue Feb 22: Exception during Send:
oracle.jms.AQjmsException: Io exception: The Network Adapter could not establish the connection
at oracle.jms.AQjmsDBConnMgr.checkForSecurityException(AQjmsDBConnMgr.java:921)
STEPS TO REPRODUCE:
Invoke the EAI JMS Transport Business Service to Send a message to the Oracle AQ queue. This will raise the error.
CauseThis issue was caused by the lack of an entry for the SOA AQ DB address on the hosts file of the TEST Siebel Server machine.
Since the hosts file was not correct, Siebel was not able to reach the machine where the AQ DB was running and thus returned the network error.
SolutionTo solve this issue, the customer added the SOA AQ DB entry to the Siebel Server's machine hosts file and rebooted the machine.
After that, Siebel was able to send messages to the JMS queue.
Thank you,
Frederico Marvila
Oracle Technical Support
ReferencesNOTE:1110467.1 - The Network Adapter Could Not Establish The Connection" (Sbl-Eai-05103)
NOTE:850954.1 - Basic Troubleshooting Steps for EAI JMS Transport
NOTE:989382.1 - JMSAdapter errors in OPMN log after PIP install
NOTE:1152994.1 - Unable To Create Jms Connection Due To Jms Exception.
Applies to: Siebel CRM - Version: 8.0.0.5 [20420] and later [Release: V8 and later ]
Information in this document applies to any platform.
***Checked for relevance on 12-JAN-2011***
Goal
The customer called the Send method on the EAI JMS Transport but the call failed with the following error:
“A JMS exception occurred in EAI JMS Transport: 'An unexpected error occurred (see StackTrace): Java heap space'.(SBL-EAI-05103)(SBL-EXL-00151)â€
The customer asked how to increase the heap size dedicated to the EAI JMS Transport.
SolutionWhen the EAI JVM Transport is called, it initializes an instance of the JVM. You can set the size of the JVM heap by including the arguments -Xms and –Xmx in the VMOPTIONS parameter in the JAVA named subsystem (type JVMSubSys). –Xms specifies the initial heap size and –Xmx specifies the maximum heap size. For example, the following specifies a 64Mb initial and 256Mb maximum heap size:
-xrs –Djms.log=C:\\jms.log –Xms64m -Xmx256m
Please note that it is out of the scope of Siebel Technical Support to provide performance tuning parameters because we do not have the means or expertise to analyze and suggest performance tuning parameters to be used on a given environment as it depends a lot on what is the platform, how many processes will be running, the available resources, the requirements and so on.
What we suggest is that the JVM default heap size is changed if issues related to the Java heap are experienced.
However if tuning the JVM heap size is really needed, we suggest the thorough execution of tests on the desired environment to see which is the best value for the JVM heap size or engage Siebel Expert Services (a billable service) as they have the expertise to analyze your environment and based on your requirements provide the best tuning parameters.
Applies to: Siebel System Software - Version: 8.0.0.1 [20408] and later [Release: V8 and later ]
z*OBSOLETE: Microsoft Windows Server 2003
Product Release: V8 (Enterprise)
Version: 8.0.0.1 [20408] FRA Fin Svcs
Database: Oracle 10.2.0.2
Application Server OS: Microsoft Windows 2003 Server
Database Server OS: Microsoft Windows 2003 Server
This document was previously published as Siebel SR 38-3507284713.
""""Checked for relevance on 19-NOV-2010""""
SymptomsJMS has been setup to work with a single JMS server and it works fine.
But while trying to connect to 2 different providers with different connection factories, errors were observed.
since jndi.properties only allows one server to be set, the information was passed through script :
function Service_PreInvokeMethod (MethodName, Inputs, Outputs)
{
if (MethodName=="initiate")
{
try{
var convBS = TheApplication().GetService("XML Hierarchy Converter");
var jmsBS = TheApplication().GetService("EAI JMS Transport");
var convPSInput = TheApplication().NewPropertySet(); // PS pour contenir l'input de la conversion � Document
var convPSEnfant1 = TheApplication().NewPropertySet(); // PS pour ajouter les valeurs de Inputs
var convPSOutput = TheApplication().NewPropertySet(); // PS pour contenir l'output de la conversion � Document
var jmsPSInput = TheApplication ().NewPropertySet (); // PS pour contenir l'input de ...
and the following error was observed :
Une exception JMS est survenue dans le transport JMS EAI : 'Exception: javax.jms.JMSSecurityException: JMS-232: An invalid user/password was specified for the JMS connection; Message: JMS-232: An invalid user/password was specified for the JMS connection'.(SBL-EAI-05103)
Causejndi.properties can work with only one vendor.
There can only be one JAVA subsystem per component task as well.
Solution
The workaround is to enable JMS receivers on different siebel servers.
One siebel server talks to one JMS vendor, and a different siebel server talks to a different vendor.
This allows a distinct jndi.properties per server and a distinct JAVA subsystem as well.
Applies to: Siebel System Software - Version: 8.1.1 SIA [21111] and later [Release: V8 and later ]
Information in this document applies to any platform.
Goal
Following error has been reported when using SOA 10g with oracle application server:
SBL-EAI-05103 / JMS-108 Error Mesaage appears,
Message of type ByteMessage not allowed with destination containing playload of type SYS$AQ_JMS_TEXT_MESSAGE
Solution
Solution:
Applying Fixpack 8.1.1.2 has resolved this issue.
Thank you
Technical Support
Applies to: Siebel System Software - Version: 7.8.2.3 SIA [19221] - Release: V7
Sun Solaris SPARC (64-bit)
Product Release: V7 (Enterprise)
Version: 7.8.2.3 [19221] DEU Com/Med
Database: Oracle 10.2.0.1
Application Server OS: Sun Solaris 10
Database Server OS: Sun Solaris 10
This document was previously published as Siebel SR 38-3167908421.
SymptomsCustomer is using Weblogic 9.2 Server as middleware for JMS messaging. The server is clustered and has two knots (there is no load balancer). In Siebel Server (Solaris 10), JAVA 1.4.2_08 is installed and Weblogic Client 8.1.4 (which is supported).
The JMS receivers can successfully connect to the Weblogic Server. But when one of the weblogic server knots is killed/shut down the tasks of our receivers that connected to that knot stop with an error, for example :-
Failed to receive messagebecause destination oip.JmsModule!oip.JmsServer.1@oip.SiebelXi.Dispatch is shutdown.'.(SBL-EAI-05103)
However, a new JMS Receiver was not automatically started, despite Default Tasks (DfltTasks) = 1, and AutoRestart=true.
CauseThis was found to be due to the siebshmw process (used to run the JMS Receiver) not exiting at the time the task failed. It took another 10 minutes for the operating system process to be killed, at which time the new JMS Receiver task was started ok.
The behavior was re-produced, and change request 12-1H1CHS2 has been logged to address the described problem.
For reference, the start of the pstack output of the siebshmw process during the 10 minutes hanging was the following :-
7dd3fe3c lwp_park (0, ffbfe1e8, 0)
7dd39ec8 cond_wait_queue (7c40f5f8, 7c40f5e0, ffbfe1e8, 0, 0, 0) + 28
7dd3a340 cond_wait_common (7c40f5f8, 7c40f5e0, ffbfe1e8, 0, 0, 0) + 298
7dd3a4d8 _cond_timedwait (7c40f5f8, 7c40f5e0, ffbfe390, 7e0f03ac, ffbfe347, 0) + 34
7dd3a5cc cond_timedwait (7c40f5f8, 7c40f5e0, ffbfe390, ff000000, 1043bc, 0) + 14
7dd3a60c pthread_cond_timedwait (7c40f5f8, 7c40f5e0, ffbfe390, 7e542000, 7c408128, 0) + c
7dfee710 void thr_t::t_sleep(timespec*,short*,int*) (7c40f5c0, ffbfe390, ffbfe3a6, ffbfe3a0, 7e0d0c6c, ffffffff) + 154
7dff2660 unsigned long MwWaitForMultipleObjects(thr_t*,unsigned long,object_t**,int,unsigned long,int,int) (7c40f5c0, 332a8a90, 0, 1a32740, 0, 52f98) + 240
7dffd728 WaitForMultipleObjectsEx (2, ffbfe6dc, 0, 100000, 0, 52f98) + 31c
7fb831cc int OSDNTWait::WaitForThread(unsigned long,int,int&) (c, 927c0, ffbfe764, 13d728, 13d400, 7fb93ec0) + 134
7f716964 OSDWaitTid (c, 927c0, ffbfe7f4, 36, 0, c) + 64
7f7b5d14 void CSSSISConn::Close() (484188, 1, 0, 7f7bcad0, 7f8423f0, c) + b4
SolutionManually killing the hanging siebshmw process allows a new receiver task to be started.
Change the impersonation approach to use Siebel specific fields in the SOAP Header to send user credentials. The SOAP XML request should be made like the example below:
z*OBSOLETE: Microsoft Windows Server 2003
Product Release: V7 (Enterprise)
Version: 7.8.2 [19213] Com/Med
Database: Microsoft SQL Server 2000 SP3
Application Server OS: Microsoft Windows 2003 Server
Database Server OS: Microsoft Windows 2003 Server
This document was previously published as Siebel SR 38-2749871082.
***Checked for relevance on 18-Nov-2010***
SymptomsWhile accessing a queue on JMS server with authentication and authorization enabled through JMS Receiver server component in Siebel 7.8.2, the required username and password to perform a JNDI look up were specified in jndi.properties file with the parameters:
java.naming.security.principal=<username>
java.naming.security.credentials=<password>
The required username and password to perform to create connections to the JMS server were specified in named subsystem of type JMSSubsys with the parameters:
ConnectionUsername
ConnectionPassword
However, the following error was caused when the JMS Receiver component attempted to make connection to the queue:
A JMS exception occurred in EAI JMS Transport: 'Exception: javax.jms.JMSSecurityException: invalid name or password; Message: invalid name or password'.(SBL-EAI-05103)
CauseIncorrect jar files were used.
Siebel Technical Support followed the same steps to provide the required username and password in jndi.properties and named subsystem but could not reproduce the same behavior in Standard Siebel 7.8.2 environment and the connection to the JMS server was created successfully. Thus, JVM log files generated in customer and Siebel Technical Support environment were compared and it was found that the following traces did not appear in JVM log from customer environment:
1:51:29.009 PM Wed Jan 4: >ConnectionFactory=QueueConnectionFactory
1:51:29.009 PM Wed Jan 4: >ConnectionUsername=siebel
1:51:29.009 PM Wed Jan 4: >ConnectionPassword=*
1:51:29.009 PM Wed Jan 4: >SendUsername=
1:51:29.009 PM Wed Jan 4: >SendPassword=*
1:51:29.009 PM Wed Jan 4: >ReceiveQueue=TEST_A
1:51:29.009 PM Wed Jan 4: >ReceiveUsername=
1:51:29.009 PM Wed Jan 4: >ReceivePassword=*
1:51:29.009 PM Wed Jan 4: >TopicUsername=
It would mean that JMS Receiver component did not send any credentials (Username and Password) to destination JMS server in customer Siebel environment. As result, the JMS server could not authenticate the JMS Receiver and the reported error was caused, even if the parameters to pass the credentials were specified properly.
Through further research, it was found that Siebel JAR files “Siebel.jar†and “SiebelJI_enu.jar†used in customer environment were not same as the ones for Siebel 7.8.2.
SolutionMake sure you use the jar files from siebsrvr/classes directory from your siebel server installation.
ReferencesNOTE:850954.1 - Basic Troubleshooting Steps for EAI JMS Transport
NOTE:859382.1 - How to Control Parameters on Transport for Outbound Web Service, e.g. HTTPSleepTime (HTTP) or SendUsername (JMS)
NOTE:971592.1 - Connect to AIA from your Enterprise via JMS
NOTE:1077448.1 - How to set up Siebel JMS with Oracle AQ
NOTE:978645.1 - Websphere MQ Supported Versions For Siebel EAI MQ Series Server Transport / EAI JMS Transport
Applies to: Siebel CRM - Version: 8.1.1 SIA [21111] and later [Release: V8 and later ]
Information in this document applies to any platform.
SymptomsWhen trying to test a send message to AIA, the following error occured
----------------------------------------------------------
Error msgbox:
----------------------------------------------------------
A JMS exception occurred in EAI JMS Transport: 'Exception: oracle.jms.AQjmsException: Io exception: The Network Adapter could not establish the connection; Message: Io exception: The Network Adapter could not establish the connection'.(SBL-EAI-05103)
Cause
Comments
--------
The error was in AIA configuration (application.xml).
The access to AIA database was done with IP+port which SOA/AIA returned to Siebel. The retuned IP was wrong, since it pointed to the AIA application server, and not the database server.
Solution
Comments
--------
The error was in AIA configuration (application.xml).
You can discover this by checking the connections done by Siebel Server to AIA, with TCPView.
It connects to OC4J_SOA on port 6003, but after it opens 14204, and then also tries to connect to AIA database (in this case, port 1523).
The access to AIA database was done with IP+port which SOA/AIA returned to Siebel. The retuned IP was wrong, since it pointed to the AIA application server, and not the database server.
Applies to: Siebel CRM - Version: 8.0 [20405] to 8.1.1 [21112] - Release: V8 to V8
""""Checked for relevance on 29-OCT-2010""""
SymptomsJMS_EXCEPTION at impersonated (SecureWebService) Inbound WS call processed by JMS Received causes inconsistent behavior: message data are updated in Siebel Db, but message self rolled back into input JMS Queue.
The behavior appears in the following sequence:
1. The JMS Receiver is set to dispatch all received message by the "SecureWebService" named subsystem (EAI Data Handling profile);
2. External application puts a message with SOAP XML request into the JMS Queue. The SOAP Header of the request includes WS-Security fields with Siebel user credentials;
3. The JMS Receiver pick ups the SOAP XML message from the JMS Queue;
4. The JMS Receiver impersonates the user (changes its session context to the specified Siebel User), by the information from WS-Security fields in the SOAP Header;
5. The received SOAP Request is get dispatched to accordant Inbound Web Service implementation (a business service or a workflow process);
6. The Web Service implementation completes the processing (for example updates or/and queries Siebel Data)
7. The EAI Transaction commits the updates in Siebel Db.
8. The JMS Receiver fails to commit the message processing to the JMS Queue (to remove the message from the Queue), because of the raised "JMS_EXCEPTION" java error without detailed information.
9. As result the message stays in the JMS Queue and can be picked up by JMS Receiver again for processing, disregarding of successful completion it at previous run.
10. The Siebel Db is updated, while the JMS Messaging Provider does not receives positive sign to remove the processed message from the JMS Queue as "committed".
* * *
This behavior has been reproduced in 8.0.0.6 SIA and 8.1.1 SIA products and may affect other 8.x Release.
The traces appearing in the JMS Receiver log (8.0.0.6 [20423] ENU) were:
"...
ObjMgrBusServiceLogObjMgrBusServiceLog InvokeMethod 4 ... Begin: Business Service 'Web Service Inbound Dispatcher' invoke method: 'Dispatch' ...
...
WebSvcInboundWebSvcInbound WSInboundTrace 3 ... Envelope Processing
WebSvcInboundWebSvcInbound WSInboundTrace 3 ... Impersonate
...
WebSvcInboundWebSvcInbound WSInboundTrace 3 ... Executing web service operation '...' by calling ...
...
WebSvcInboundWebSvcInbound WSInboundTrace 3 ... Completed inbound web service execution.
...
ObjMgrBusServiceLogObjMgrBusServiceLog InvokeMethod 4 ... End: Business Service 'Web Service Inbound Dispatcher' invoke method: 'Dispatch' ...
EAITransport EAITransportGenericEAITransportGeneric 3 ... Dispatch Service: 'Web Service Inbound Dispatcher', Method: 'Dispatch' completed successfully
ObjMgrBusServiceLogObjMgrBusServiceLog InvokeMethod 4 ... Business Service 'EAI Transport Dispatch Service' invoke method 'GenericDispatch' ...
ObjMgrBusServiceLogObjMgrBusServiceLog InvokeMethod 4 ... End: Business Service 'EAI Transport Dispatch Service' invoke method: 'GenericDispatch' ...
ObjMgrBusServiceLogObjMgrBusServiceLog Delete 4 ... Business Service 'EAI Transport Dispatch Service' ... was unregsitered ...
ObjMgrBusServiceLogObjMgrBusServiceLog Delete 4 ... Business Service 'EAI Transport Dispatch Service' was deleted ...
ObjMgrSessionLogObjMgrSessionLog Warning 2 ... (physmod.cpp (4998)) SBL-DAT-00473: No transaction is in progress
ObjMgrBusServiceLogObjMgrBusServiceLog Create 4 ... Business Service 'EAI JMS Java Business Service Caller' was created ...
ObjMgrBusServiceLogObjMgrBusServiceLog Create 4 ... Business Service 'EAI JMS Java Business Service Caller' ... was regsitered ...
EAITransport EAITransportDebugEAITransportDebug 4 ... Invoking JMS Java method Commit
ObjMgrBusServiceLogObjMgrBusServiceLog InvokeMethod 4 ... Begin: Business Service 'EAI JMS Java Business Service Caller' invoke method: 'Commit' ...
...
EAITransport EAITransportDebugEAITransportDebug 4 ... Finished copying properties
EAITransport EAITransportDebugEAITransportDebug 4 ... Finished copying type
EAITransport EAITransportDebugEAITransportDebug 4 ... Finished copying value
EAITransport EAITransportDebugEAITransportDebug 4 ... End Creating instance of output property set
...
ObjMgrBusServiceLogObjMgrBusServiceLog Error 1 ... (javabsvc.cpp (181)) SBL-EAI-05000: Business Service call returned error code JMS_EXCEPTION and message: An unexpected error occurred (see StackTrace): null
ObjMgrBusServiceLogObjMgrBusServiceLog InvokeMethod 4 ... Business Service 'EAI JMS Java Business Service Caller' invoke method 'Commit' ...
ObjMgrBusServiceLogObjMgrBusServiceLog InvokeMethod 4 ... End: Business Service 'EAI JMS Java Business Service Caller' invoke method: 'Commit' ...
ObjMgrBusServiceLogObjMgrBusServiceLog Error 1 ... (jmsbsvc.cpp (323)) SBL-EAI-05103: A JMS exception occurred in EAI JMS Transport: 'An unexpected error occurred (see StackTrace): null'.
ObjMgrBusServiceLogObjMgrBusServiceLog InvokeMethod 4 ... Business Service 'EAI JMS Transport' invoke method 'ReceiveDispatch' ...
ObjMgrBusServiceLogObjMgrBusServiceLog InvokeMethod 4 ... End: Business Service 'EAI JMS Transport' invoke method: 'ReceiveDispatch' ...
..."
The SOAP XML Request was made like the example below:
<s:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" ...>
<s:Header>
<ws:Security xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/07/secext">
<ws:UsernameToken>
<ws:Username>...</ws:Username>
<ws:Password ..>...</ws:Password>
</ws:UsernameToken>
</ws:Security>
</s:Header>
<s:Body>...</s:Body>
</s:Envelope>
Cause
We presume, that user context change used in the impersonation approach at each incoming Web Service call caused reset of outstanding transaction flags.
Working without user context changing prevents occurrence of the behavior.
The Change Request BUG 10565450 has been logged to address this case.
Solution1. WORKAROUND, verified for Siebel 8.1.1 Release:
<s:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:s2="http://siebel.com/webservices" ...>
<s:Header>
<s2:UsernameToken>...</s2:UsernameToken>
<s2:PasswordText>...</s2:PasswordText>
<s2:SessionType>None</s2:SessionType> </s:Header>
<s:Body>...</s:Body>
</s:Envelope>
This workaround may not help in Siebel 8.0 Release.
2. WORKAROUND, verified for Siebel 8.0 and Siebel 8.1.1 Release:
Change the intgeration approach to not use impersonation feature for Inbound Web Service calls (SOAP XML requests), received and processed by the JMS Receiver task.
Using of the "WebService" EAI Data Handling subsystem will keep the integration working. The only side effect of this solution is that the context of the JMS Receiver user (specified in the component parameters) will be used for processing of all messages.
ReferencesBUG:10565450 - JMS_EXCEPTION AT 'COMMIT' OF 'EAI JMS JAVA BUSINESS SERVICE CALLER' FOR INBOUND WS WITH WSSE-AUTH.
NOTE:850954.1 - Basic Troubleshooting Steps for EAI JMS Transport
NOTE:1076251.1 - Master Note for Siebel Web Services
Applies to: Siebel CRM Call Center - Version: 8.1.1.3 SIA[21219] and later [Release: V8 and later ]
Information in this document applies to any platform.
SymptomsSIEBEL VERSION: 8.1.1.3
ISSUE STATEMENT:
JMS connections from Siebel to Oracle AQ are not working on the TEST environment while they work correctly on the DEV one.
ERROR:
7:06:51.853 AM Tue Feb 22: Exception during Send:
oracle.jms.AQjmsException: Io exception: The Network Adapter could not establish the connection
at oracle.jms.AQjmsDBConnMgr.checkForSecurityException(AQjmsDBConnMgr.java:921)
STEPS TO REPRODUCE:
Invoke the EAI JMS Transport Business Service to Send a message to the Oracle AQ queue. This will raise the error.
CauseThis issue was caused by the lack of an entry for the SOA AQ DB address on the hosts file of the TEST Siebel Server machine.
Since the hosts file was not correct, Siebel was not able to reach the machine where the AQ DB was running and thus returned the network error.
SolutionTo solve this issue, the customer added the SOA AQ DB entry to the Siebel Server's machine hosts file and rebooted the machine.
After that, Siebel was able to send messages to the JMS queue.
Thank you,
Frederico Marvila
Oracle Technical Support
ReferencesNOTE:1110467.1 - The Network Adapter Could Not Establish The Connection" (Sbl-Eai-05103)
NOTE:850954.1 - Basic Troubleshooting Steps for EAI JMS Transport
NOTE:989382.1 - JMSAdapter errors in OPMN log after PIP install
NOTE:1152994.1 - Unable To Create Jms Connection Due To Jms Exception.
Applies to: Siebel CRM - Version: 8.0.0.5 [20420] and later [Release: V8 and later ]
Information in this document applies to any platform.
***Checked for relevance on 12-JAN-2011***
Goal
The customer called the Send method on the EAI JMS Transport but the call failed with the following error:
“A JMS exception occurred in EAI JMS Transport: 'An unexpected error occurred (see StackTrace): Java heap space'.(SBL-EAI-05103)(SBL-EXL-00151)â€
The customer asked how to increase the heap size dedicated to the EAI JMS Transport.
SolutionWhen the EAI JVM Transport is called, it initializes an instance of the JVM. You can set the size of the JVM heap by including the arguments -Xms and –Xmx in the VMOPTIONS parameter in the JAVA named subsystem (type JVMSubSys). –Xms specifies the initial heap size and –Xmx specifies the maximum heap size. For example, the following specifies a 64Mb initial and 256Mb maximum heap size:
-xrs –Djms.log=C:\\jms.log –Xms64m -Xmx256m
Please note that it is out of the scope of Siebel Technical Support to provide performance tuning parameters because we do not have the means or expertise to analyze and suggest performance tuning parameters to be used on a given environment as it depends a lot on what is the platform, how many processes will be running, the available resources, the requirements and so on.
What we suggest is that the JVM default heap size is changed if issues related to the Java heap are experienced.
However if tuning the JVM heap size is really needed, we suggest the thorough execution of tests on the desired environment to see which is the best value for the JVM heap size or engage Siebel Expert Services (a billable service) as they have the expertise to analyze your environment and based on your requirements provide the best tuning parameters.
Applies to: Siebel System Software - Version: 8.0.0.1 [20408] and later [Release: V8 and later ]
z*OBSOLETE: Microsoft Windows Server 2003
Product Release: V8 (Enterprise)
Version: 8.0.0.1 [20408] FRA Fin Svcs
Database: Oracle 10.2.0.2
Application Server OS: Microsoft Windows 2003 Server
Database Server OS: Microsoft Windows 2003 Server
This document was previously published as Siebel SR 38-3507284713.
""""Checked for relevance on 19-NOV-2010""""
SymptomsJMS has been setup to work with a single JMS server and it works fine.
But while trying to connect to 2 different providers with different connection factories, errors were observed.
since jndi.properties only allows one server to be set, the information was passed through script :
function Service_PreInvokeMethod (MethodName, Inputs, Outputs)
{
if (MethodName=="initiate")
{
try{
var convBS = TheApplication().GetService("XML Hierarchy Converter");
var jmsBS = TheApplication().GetService("EAI JMS Transport");
var convPSInput = TheApplication().NewPropertySet(); // PS pour contenir l'input de la conversion � Document
var convPSEnfant1 = TheApplication().NewPropertySet(); // PS pour ajouter les valeurs de Inputs
var convPSOutput = TheApplication().NewPropertySet(); // PS pour contenir l'output de la conversion � Document
var jmsPSInput = TheApplication ().NewPropertySet (); // PS pour contenir l'input de ...
and the following error was observed :
Une exception JMS est survenue dans le transport JMS EAI : 'Exception: javax.jms.JMSSecurityException: JMS-232: An invalid user/password was specified for the JMS connection; Message: JMS-232: An invalid user/password was specified for the JMS connection'.(SBL-EAI-05103)
Causejndi.properties can work with only one vendor.
There can only be one JAVA subsystem per component task as well.
Solution
The workaround is to enable JMS receivers on different siebel servers.
One siebel server talks to one JMS vendor, and a different siebel server talks to a different vendor.
This allows a distinct jndi.properties per server and a distinct JAVA subsystem as well.
Applies to: Siebel System Software - Version: 8.1.1 SIA [21111] and later [Release: V8 and later ]
Information in this document applies to any platform.
Goal
Following error has been reported when using SOA 10g with oracle application server:
SBL-EAI-05103 / JMS-108 Error Mesaage appears,
Message of type ByteMessage not allowed with destination containing playload of type SYS$AQ_JMS_TEXT_MESSAGE
Solution
Solution:
Applying Fixpack 8.1.1.2 has resolved this issue.
Thank you
Technical Support
Applies to: Siebel System Software - Version: 7.8.2.3 SIA [19221] - Release: V7
Sun Solaris SPARC (64-bit)
Product Release: V7 (Enterprise)
Version: 7.8.2.3 [19221] DEU Com/Med
Database: Oracle 10.2.0.1
Application Server OS: Sun Solaris 10
Database Server OS: Sun Solaris 10
This document was previously published as Siebel SR 38-3167908421.
SymptomsCustomer is using Weblogic 9.2 Server as middleware for JMS messaging. The server is clustered and has two knots (there is no load balancer). In Siebel Server (Solaris 10), JAVA 1.4.2_08 is installed and Weblogic Client 8.1.4 (which is supported).
The JMS receivers can successfully connect to the Weblogic Server. But when one of the weblogic server knots is killed/shut down the tasks of our receivers that connected to that knot stop with an error, for example :-
Failed to receive messagebecause destination oip.JmsModule!oip.JmsServer.1@oip.SiebelXi.Dispatch is shutdown.'.(SBL-EAI-05103)
However, a new JMS Receiver was not automatically started, despite Default Tasks (DfltTasks) = 1, and AutoRestart=true.
CauseThis was found to be due to the siebshmw process (used to run the JMS Receiver) not exiting at the time the task failed. It took another 10 minutes for the operating system process to be killed, at which time the new JMS Receiver task was started ok.
The behavior was re-produced, and change request 12-1H1CHS2 has been logged to address the described problem.
For reference, the start of the pstack output of the siebshmw process during the 10 minutes hanging was the following :-
7dd3fe3c lwp_park (0, ffbfe1e8, 0)
7dd39ec8 cond_wait_queue (7c40f5f8, 7c40f5e0, ffbfe1e8, 0, 0, 0) + 28
7dd3a340 cond_wait_common (7c40f5f8, 7c40f5e0, ffbfe1e8, 0, 0, 0) + 298
7dd3a4d8 _cond_timedwait (7c40f5f8, 7c40f5e0, ffbfe390, 7e0f03ac, ffbfe347, 0) + 34
7dd3a5cc cond_timedwait (7c40f5f8, 7c40f5e0, ffbfe390, ff000000, 1043bc, 0) + 14
7dd3a60c pthread_cond_timedwait (7c40f5f8, 7c40f5e0, ffbfe390, 7e542000, 7c408128, 0) + c
7dfee710 void thr_t::t_sleep(timespec*,short*,int*) (7c40f5c0, ffbfe390, ffbfe3a6, ffbfe3a0, 7e0d0c6c, ffffffff) + 154
7dff2660 unsigned long MwWaitForMultipleObjects(thr_t*,unsigned long,object_t**,int,unsigned long,int,int) (7c40f5c0, 332a8a90, 0, 1a32740, 0, 52f98) + 240
7dffd728 WaitForMultipleObjectsEx (2, ffbfe6dc, 0, 100000, 0, 52f98) + 31c
7fb831cc int OSDNTWait::WaitForThread(unsigned long,int,int&) (c, 927c0, ffbfe764, 13d728, 13d400, 7fb93ec0) + 134
7f716964 OSDWaitTid (c, 927c0, ffbfe7f4, 36, 0, c) + 64
7f7b5d14 void CSSSISConn::Close() (484188, 1, 0, 7f7bcad0, 7f8423f0, c) + b4
SolutionManually killing the hanging siebshmw process allows a new receiver task to be started.
Related
Products
Siebel > Customer Relationship Management > CRM - Enterprise Edition > Siebel System Software
Keywords
| |
AUTOMATICALLY STARTED; HANGING; WEBLOGIC; SOLARIS; JMS
| |
Errors
| |
SBL-EAI-05103
| |
Change the impersonation approach to use Siebel specific fields in the SOAP Header to send user credentials. The SOAP XML request should be made like the example below:
No comments:
Post a Comment