SBL-EAI-04239: Unable to put a message to MQSeries Queue '%1'rMQSeries Error Code: %2

Applies to:

Siebel CRM - Version: 7.8.2.7 [19234] - Release: V7



Information in this document applies to any platform.



Symptoms

Siebel 'EAI MQSeries Server Transport' business service method 'Send' is not able to post data to MQ server when the message size is more than 4MB in size.



When sending more than 4MB message size, the 'EAI MQSeries Server Transport' business service method 'Send' returns the following error message:



Error Code: (SBL-BPR-00162)--(SBL-EAI-04239)

Error Messsage: Error invoking service 'EAI MQSeries Server Transport', method 'Send' at step 'Send to MQ'.(SBL-BPR-00162)

--

Unable to put a message to MQSeries Queue 'QUEUE_NAME'

MQSeries Error Code: 2030(SBL-EAI-04239)



Cause

The cause of the problem/error occurring when posting a message greater than 4MB is due to the IBM MQ Series 'Maximum Message Length' setting at the Queue Manager and Queue level set to a default of 4194304 bytes, which is roughly 4MB for the maximum message size that MQ can accept.



According to IBM's website, the error code 2030 and 2031 have the following error message and meaning:



MQRC_MSG_TOO_BIG_FOR_Q 2030

MQRC_MSG_TOO_BIG_FOR_Q_MGR 2031



The 'Maximum Message Length' exists in IBM MQ Series at both the MQ Queue Manager and Queue level. The setting for this 'Maximum Message Length' field needs to be set the same value at both the Queue Manager and Queue level that the application is trying to send to.



When the 'Maximum Message Length' is only 4194304 bytes, this means it can only accept messages with roughly 4 MB.



These error codes are documented on IBM's website:



http://www-01.ibm.com/support/docview.wss?rs=171&uid=swg21154055



2030 MQRC MSG TOO BIG FOR Q



Problem(Abstract)

MQPUT fails and you receive the following:



2030 X’07EE’ MQRC_MSG_TOO_BIG_FOR_Q



Cause

The message length exceeds the maxmsgl specified in the WebSphere® MQ queue manager, queue and channel definitions.



Solution

In order to fix this problem and prevent the error, the following steps should be performed:



1. Change the 'Maximum Message Length' to a higher value (50000000 for 50 MB) at both Queue Manager and Queue level:



- MQSeries Explorer > MQ Queue Manager > Properties > Extended tab > 'Maximum Message Length' field



- MQSeries Explorer > Queue > Properties > Extended tab > 'Maximum Message Length' field



If Channels are being used, then also change the 'Maximum Message Length' at the Channels as well.



Please note: The maximum message length supported by IBM MQSeries is 100MB.



Then, restart the IBM MQSeries services.



2. Then, restart the Siebel server services.



3. Then, run the test case using Siebel 'EAI MQSeries Server Transport' service 'Send' method to post messages greater than 4MB, but less than 50MB (or, less than whatever the 'Maximum Message Length' field value is).



A documentation change request has been logged to have the MQ 'Maximum Message Length' parameter documented in Siebel Bookshelf > Transports and Interfaces: Siebel Enterprise Application Integration > EAI MQSeries Transport section:



CR # 10564577 - MQSeries 'Maximum Message Length' needs to be increased in to send messages greater than 4MB























Applies to:

Siebel System Software - Version: 7.5.3.1 SIA [16161] - Release: V7

z*OBSOLETE: Microsoft Windows 2000

Product Release: V7 (Enterprise)

Version: 7.5.3.1 [16161] Fin Svcs

Database: Oracle 9.2.0.2

Application Server OS: Microsoft Windows 2000 Server SP 3

Database Server OS: IBM AIX 5L 5.1



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

Symptoms

The EAI MQSeries Server Transport is being called from a Workflow running in the Business Integration Manager (BIM) component, to write messages to an outbound MQ.



After some time, MQ Open error messages are reported in the BIM log files. After that none of the messages get written to MQ unless the component is re-started.



The error messages are :-



GenericLog GenericError 1 2004-04-15 12:21:04 Object manager error: ([0] Unable to put a message to MQSeries Queue 'MQCR.CUSTOMER.MARS.CONTACT'



MQSeries Error Code: 2018(SBL-EAI-04239) (0x808d))

GenericLog GenericError 1 2004-04-15 12:21:04 Object manager error: ([1] Error invoking service 'EAI MQSeries Server Transport', method 'Send' at step 'EAI MQSeries Server Transport'.(SBL-BPR-00162) (0x80d8))



GenericLog GenericError 1 2004-04-15 12:21:04 ((0) err=4300107 sys=32984) SBL-OMS-00107: Object manager error: ([1] Error invoking service 'EAI MQSeries Server Transport', method 'Send' at step 'EAI MQSeries Server Transport'.(SBL-BPR-00162) (0x80d8))



GenericLog GenericError 1 2004-04-15 12:21:04 ((0) err=4300107 sys=32909) SBL-OMS-00107: Object manager error: ([0] Unable to put a message to MQSeries Queue 'MQCR.CUSTOMER.MARS.CONTACT'

MQSeries Error Code: 2018(SBL-EAI-04239) (0x808d))







Cause

The customer had cached the 'EAI MQ Series Server Transport' Business Service.



The Bookshelf mentions that the 'EAI MQ Series Server Transport' should not be cached when transport will be called within the Workflow Process Manager (or BIM) server component, see Bookshelf reference :-



Tuning Siebel EAI for Performance > Best Practices for Siebel EAI Tuning



Caching of the MQSeries Transport business services can improve outbound performance by eliminating the need to connect to the queue for each message. Caching is disabled by default because it is not usable in every situation. Follow these tips to enable caching :-



1) Only cache in client sessions. Do not use caching if your transport will be called within the Workflow Process Manager server component. The threading model of these components is not compatible with the MQSeries APIs.

2) To enable caching, turn on the Service Cache flag in Siebel Tools and then recompile the .srf file. 3) If you need to call the WebSphere MQ Transport in Workflow Process Manager and in a client session, make a separate copy of the service (one cached and one uncached) for each situation.

4) Caching occurs on a per-queue basis and only one connection is kept open at a time. If a single session is going to talk to multiple queues, consider making a copy of the transport for each outbound queue.







Solution

The error did not re-occur after the 'EAI MQ Series Server Transport' was uncached.























Applies to:

Siebel System Software - Version: 7.5.3.6 [16186] - Release: V7

IBM AIX on POWER Systems (64-bit)

Product Release: V7 (Enterprise)

Version: 7.5.3.6 [16186]

Database: Oracle 9i

Application Server OS: IBM AIX 5L 5.1

Database Server OS: IBM AIX 5L 5.1



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

Symptoms

Hi,



What happens when an inbound message is already dispatched to WF (using ReceiveSendDispatch method of the MQReceiver) and while the message is being handled, MQ queue mgr fails and both the response and inbound queues become unavailable. Siebel Transactions and Rollback on dispatch error properties are set, but in this case, the message could not be returned to the inbound queue, will it be lost? Or will the component somehow cache it?



Cause

xxxx

Solution

Message 1

For the benefit of other users, ReceiverMethodName was set to ReceiveDispatchSend for the MQ Series Server Receiver (MQSeriesSrvRcvr) and RollbackOnDispatchError and SiebelTransactions were set to True for the EAITransportDataHandlingSubsys. The customer wanted to know what happens if the response queue and the inbound queue become unavailable while a message is being processed by Siebel.



I carried out some testing. As part of this I created a workflow that waits for 3 minutes before returning a value. For the EAITransportDataHandlingSubsys RollbackOnDispatchError and SiebelTransactions are set to True. The MQSeriesServerSubsys is configured as follows:



MqPhysicalQueueName: TEST.QUEUE

MqModelQueueName: QM_eghtsgps06

MqRespPhysicalQueueName: TEST.QUEUE.RESP



The Default Persistence property of the queue was set to Not Persistent. I started a MQ Series Server Receiver (MQSeriesSrvRcvr) task and put a message onto TEST.QUEUE. The MQSeriesSrvRcvr task started to execute the workflow and while it was waiting I stopped the IBM MQSeries component service which provides startup and maintenance services for WebSphere MQ. In WebSphere MQ Explorer I noted that my queue manager shut down and the queues disappeared.



After 3 minutes the MQSeriesSrvRcvr task executed the remainder the workflow. The task then failed with an error and the log file included the following information:



[Continued]



Message 2

[Continued]



Sending Response (SBL-EAI-04239) Unable to put a message to MQSeries Queue 'TEST.QUEUE.RESP' Rolling back Siebel transaction Closed MQSeries Queue: 'TEST.QUEUE.RESP' (SBL-EAI-04240) MQSeries Rollback Transaction failed: Queue Manager: 'QM_eghtsgps06', Queue: 'TEST.QUEUE' Closed MQSeries Queue: 'TEST.QUEUE' Disconnected from MQSeries Queue Manager: 'QM_eghtsgps06'

(smisched.cpp 17(603) err=3500953 sys=0) SBL-EAI-00953: Call of Service 'SBL-EAI-00953: Call of Service 'EAI MQSeries Server Transport', Method 'ReceiveDispatchSend' failed: 32909', Method '(null)' failed: (null)



As you can see, the MQSeriesSrvRcvr tried to put a message on the response queue but of course it could not. RollbackOnDispatchError was set to True so it then tried to put the message back onto the queue (i.e. rollback the transaction) but again it could not.



I then restarted the IBM MQSeries component service. In WebSphere MQ Explorer I noted that my queue manager started up, the queues reappeared but the message that I put on the queue did not reappear.



I changed the Default Persistence property of the queue from Not Persistent to Persistent and repeated the test. Exactly the same thing happened as with the first test but this time when I restarted the IBM MQSeries component service the message reappeared. This is because the messages on the queue are now persisted.



[Continued]



Message 3

[Continued]



When I started another MQSeriesSrvRcvr task the message was picked up from the queue again and this time a message was correctly put on the response queue.



Testing showed that messages are not cached by Siebel. However, if a message cannot be put on the response queue Siebel will try to roll back the message to the original queue. Also, if the queue and the response queue are unavailable and the queue or a message put on a queue is persisted, the message is not lost and will be picked up again when everything is up and running.



Message processing takes place within a transaction which is similar to a database transaction. When a message is picked up from the inbound queue a transaction is started. After Siebel has processed the inbound message and put a message on the response queue, it will send a commit to MQSeries which will then remove the message from the inbound queue. The message will be not be removed until a commit is received.



- Siebel Technical Support



Keywords: MQ Series Server Receiver MQSeriesSrvRcvr ReceiverMethodName ReceiveDispatchSend RollbackOnDispatchError SiebelTransactions True EAITransportDataHandlingSubsys Inbound Response Queue Error Message MQSeries Default Persistence