This portal is to open public enhancement requests for IBM Sterling products and services. To view all of your ideas submitted to IBM, create and manage groups of Ideas, or create an idea explicitly set to be either visible by all (public) or visible only to you and IBM (private), use the IBM Unified Ideas Portal (https://ideas.ibm.com).
Shape the future of IBM!
We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:
Search existing ideas
Start by searching and reviewing ideas and requests to enhance a product or service. Take a look at ideas others have posted, and add a comment, vote, or subscribe to updateson them if they matter to you. If you can't find what you are looking for,
Post your ideas
Post an idea.
Get feedback from the IBM team and other customers to refine your idea.
Follow the idea through the IBM Ideas process.
Specific links you will want to bookmark for future use
Sterling Integrator JMS Adapter Issue in consuming messages
There is an issue that happens when an outside source sends a file with a “null” message inside the message body to the B2Bi JMS adapter: the Sterling JMS adapter process is going into an endless loop when receiving the Null value inside the body of a client file.
jms.log in debug showed messages stuck on JMS TIBCO queue are null messages. (Text=null)
The adapter is failing to read/understand how to handle the “null” messages, therefore produces the endless loop error. After a restart the adapter only has a few messages that are read/understood and processed. Is there any way to avoid the continual loop response that is currently how the application works (which can end up with so many error responses that it ends up crashing the system/database) and make it so that when the “null” message is received that a single error message is produced instead of the continual error loop?
Support has stated to work with the customer and the producing application which would change the incoming message body from “null” to empty as the fix. However, we would like to see this “null” in the message body treated as a bug with an alternate option for a “null” message body that would, instead of causing an endless loop of continually produced error messages, produce one single error message and possibly a notification alert that the error occurred
What is your industry?
How will this idea be used?
When an upstream application sends any empty body message, those messages are causing the processing to stop. We need the JMS Queue processing to continue so that valid messages can be consumed.
At the very least we need some type of notification when the processing stops, so that we can take action proactively.
Do not place IBM confidential, company confidential, or personal information into any field.