Technical Articles
Cloud Integration – JMS Resource and Size Limits
This blog describes the resource and size limits for JMS resources used in the JMS, XI and AS2 adapter, that can be used in Cloud Integration Enterprise Edition and Integration Suite Standard and Premium. It describes which limits apply and how to monitor them. It also gives some guidance on how to cleanup the resources.
JMS Resource and Size Limits
The connected JMS messaging instance, that is used in asynchronous messaging scenarios using with the JMS, XI or AS2 Adapter has limited resources.
There are also technical restrictions on the size of the headers and exchange properties that can be stored in the JMS queue.
Resource Limits for SAP Cloud Integration Enterprise Edition and in SAP Integration Suite
In the Cloud Integration Enterprise Edition and in the Integration Suite, a dedicated set of resources is provisioned per default in the JMS instance, which can be introduced via self-service. Keep this in mind when configuring and running your scenarios.
Default provisioned resources:
- Number of Queues in Cloud Integration: 30
- JMS Resources for Monitoring
- Total Queue Capacity: 9,3GB
- Maximum Capacity for one Queue: 95% of the Total Queue Capacity
- Transactions: 150
- Consumers: 150
- Providers: 150
- Maximum Messages in one Transaction: 256
- Message Volume: 150GB/month
It is possible to increase the JMS resources via self-service for up to 100 queues as described in detail in the blog Activating and Managing Enterprise Messaging Capabilities.
NOTE: If you have a use case of requiring more than 100 queues, you need to create an incident following the KBA 2589823
It is possible to assign additional Enterprise Messaging units containing one queue and a dedicated set of JMS resources.
5 Enterprise Messaging Units consist of:
- Number of JMS Queues in Cloud Integration: 1
- Queue Capacity: 300MB
- Transactions: 5
- Consumers: 5
- Providers: 5
- Message Volume: 5GB/month
Sample resources for 100 message queues:
- Number of JMS Queues in Cloud Integration: 100
- Queue Capacity: 30GB
- Transactions: 500
- Consumers: 500
- Providers: 500
- Message Volume: 500GB/month
Limits not related to the numbers of Enterprise Messaging Units:
- Maximum Capacity for one Queue: 95% of the Total Queue Capacity
- Maximum Messages in one Transaction: 256
JMS Resources
The JMS Resources are shown in the Queue Monitor in the Manage Storages section in the Operations view:
If the JMS Resources get critical the message appears as a yellow warning message. If the JMS resources are exhausted, it appears as a red error message.
If the resources are exhausted, messages can no longer be processed, so you need to keep an eye on this value. Make sure that there are no messages stuck in queues!
Using the Details link you get the detailed overview of the JMS Resources:
How to activate alerting for the JMS Resources is described in the blog Automated Notification for Critical or Exhausted JMS Resources.
Number of Queues
JMS queues are used by the JMS, AS2 and XI adapter. When the first integration flow that uses a JMS queue is deployed, the queue is created in the messaging broker. The queue can then be used for sending messages into the queue and for consuming messages from the queue.
The status for Number of Queues gets Critical if only one queue is left. In the above case it would get the critical status when 28 queues are created and only one is left.
The status for Number of Queues is never Exhausted because there is no impact in runtime. If you would deploy a new integration flow using a new queue you would get an error during deployment of the integration flow.
Queue Deletion
If you no longer need a specific queue, (for example if the integration flow has been undeployed), you have to delete the queue manually in the Queue Monitor.
If the queue limit has been reached, you can check for unused queues and delete them. For more information about checks for unused queues, see the blog ‘Checks in Queue Monitor’.
Total Queue Capacity
The total queue capacity used by all the scenarios is shown in the JMS Resources.
If the overall capacity used reaches 80% of the total capacity available, the status gets Critical. If 95% of the available capacity is used, the status gets Exhausted/Error.
If 100% of the total queue capacity is reached, messages can no longer be processed in the queues, so you need to keep an eye on this value or setup an automated notification as suggested above. Make sure that consumers are registered for the queues and that no messages are stuck in queues!
Queue Status
In addition to the overall queue capacity there is also a limit per queue. One queue might currently use 95% of the total queue capacity. With the 8-December-2019 release you have the option to configure this size for each of your JMS queues separately. This feature allows you to prevent that one overloaded queue affects other scenarios.
If at least one queue has a warning status, the Queue Status goes to Critical shown in orange color, if at least one queue has an error status, the Queue Status goes to Error and is shown in red.
The master view of the queue monitor shows the status for the individual queues. The Status column shows a warning or error icon if the size of this queue reaches a critical limit. The warning icon is shown if more than 80% of the queue size is reached, if 95% or more of the configured queue size is reached an error icon is shown.
To get the detailed status for the queue, click on the Status action from the menu:
You can see that the selected queue has three sub-queues required for the processing of the messages:
- Processing Queue: Here, the main processing takes place. Messages are stored there using the JMS receiver and are consumed from it using the JMS sender.
- Error Queue: Here, messages in error are parked until the next configured retry. From this queue messages are not consumed; the messages are put back to the processing queue when the configured retry interval is reached.
- Chunking Queue: Messages larger than 5MB are split into one 5MB parent message and multiple chunks, because the message broker does not support messages over a certain message size. The single chunk messages have a size limit of a maximum of 5MB. The parent message is stored in the processing queue while the multiple chunks are stored in the chunking queue.
For example, a 46MB message would be split into one 5MB parent message stored in the processing queue, and eight 5MB and one 1MB chunk messages stored in the chunking queue.
In case such a large message runs into an error, the parent message is moved to the error queue, but the chunk messages are kept in the chunking queue. The retry is triggered once the parent message is moved back to the processing queue after the configured retry interval.
It is important to understand the difference between the sub-queues when you configure the sizes as the sizes can be configured on each of the sub-queues. The size can be configured using the Configure Size option in the Queue Status view or the Configure Size action in the menu for the queue:
In the Configure Queues Sizes view you define the size for each sub-queue in MB. The default for each queue is 95% of the total queue capacity on the broker. The size can be configured to any value between 100MB and 95% of the total queue capacity.
Note, that you can also configure a size that is lower than the current queue size. In this case no further messages can be sent to the queue until enough messages are consumed from this queue and free space is available.
Active/Stopped Queue Status
In the master view a queue is also shown with a red error sign if it is in Stopped status:
A stopped queue can be started with the Start action in this Queue Status View.
If there are problems in an integration scenario and you want to avoid that the JMS resources are eaten up by this scenario you are able to stop a queue. A stopped queue is not processing any messages anymore, it is neither possible to store messages anymore in this queue, not consume from this queue. This can be done as administrative action via the action Stop in the Queue Status View for a queue:
Transactions, Consumers and Providers
To process a message during runtime always a consumer or provider and an open transaction are required. If a message is stored to JMS queue (JMS Receiver channel) a provider is required, for polling a message from JMS queue (JMS sender channel) a consumer is required.
If the JMS Resources get Critical you need to optimize the usage of transactions in consumers and providers or increase the message queue quota. If more than 100 message queues or equivalent JMS resources are required follow note 2589823.
Think about the following technical details:
Consumers
Consumers are created in the JMS broker from JMS sender, AS2 sender and XI sender and receiver adapters to consume messages from a JMS queue. There is a minimum number of consumers that are always created for the deployed integration flows having JMS queues, independent of the message throughput, and a maximum number that is started when many messages are stored in the JMS queues and need to be consumed.
Minimum number of consumers:
For each JMS queue used in a JMS, AS2 or XI sender or receiver channel a minimum of one consumer is created for each runtime node started in the Cloud Integration cluster.
In short, the minimum number of consumers for a tenant can be calculated like this:
Cmin = number of worker nodes * number of JMS queues
Maximum number of consumers:
If lots of messages are to be consumed from the JMS queue, the initially created consumer is dynamically increased up to the configured Number of Concurrent Processes in the JMS or AS2 channel to provide a higher message throughput. For each JMS queue used in a JMS or AS2 sender channel, a maximum of consumers is created as concurrent processes are configured in the JMS or AS2 sender channel in parameter Number of Concurrent Processes. If several runtime nodes are started in the Cloud Integration cluster those many consumers are created from each runtime node.
If the XI sender or receiver adapter is used with a JMS queue as temporary storage, only one consumer is started.
In short, the maximum number of consumers for a tenant can be calculated like this:
Cmax = number of runtime nodes * total number of concurrent processes in all JMS queues
Note that the numbers of runtime nodes is shown in the JMS Resources view after the 25-November-2018 update at the very end of the screen. Before the November update this was not explicitly shown in the WebUI. The only option you had then, was to count the numbers of system log files (ljs_trace_*) written in parallel in your tenant. In the System Log Files monitor you could check how many ljs_trace* files are written at the same time. It’s one for each runtime node.
Note, that additional consumers are created for monitoring (when the Queue Monitor is used) and in case large messages are processed.
To reduce the parallel consumers, you can either reduce the number of concurrent processes in the JMS sender channels or reduce the number of runtime nodes started in the cluster.
Providers
Providers are created by the JMS receiver, AS2 sender and XI sender and receiver adapter in the JMS broker to store messages in a JMS queue. As many providers are created as messages are send to the JMS queue in parallel. The number of providers created is dynamically increased as long as enough providers and transactions are available.
In short, the number of providers for a tenant cannot be calculated, but depend on the sender system:
P = number of parallel sender calls
Note, that additional providers are created in case large messages are processed.
To reduce the parallel providers, you need to reduce the parallelism of the inbound processing by reducing the number of parallel inbound calls from sender systems sending messages to scenarios using JMS queues.
Transactions
To consistently process messages, JMS transactions are required in the JMS broker to be able to consistently roll back the processing in case of errors. As many transactions are created in the JMS broker as consumers and providers are under processing in parallel. This means, that for every consumer and every provider a transaction is started.
In short, the minimum number of transactions for a tenant can be calculated like this:
Tmin = Cmin + P
And the maximum number of transactions for a tenant can be calculated like this:
Tmax = Cmax + P
There are 150 open transactions available in the JMS broker, they can be used for a consumer or for a provider. The transactions are distributed dynamically to providers and consumers. This means, if lots of messages are consumed in parallel in consumers (polling messages form JMS queues via JMS, AS2 sender or XI sender and receiver channels) most of the transactions will be used for those and the number of available transactions to store message to JMS queues is lower.
If the limit for transactions is reached (if you get a runtime error) you need to reduce the parallelism for the consumers and/or providers (see above).
If multiple JMS resources, like JMS, XI or AS2 Sender Adapters and/or one or more JMS Receiver Adapters are used in one integration flow you can optimizes the numbers of used transactions in the JMS instance using a JMS transaction handler because then only one transaction is opened for the whole processing. More details about this option you can find in blog ‘How to configure transaction handling in integration flow/‘.
Numbers of Messages in one Transaction
There is a maximum of 256 messages allowed in one transaction. This is important to know for split scenarios, where multiple split messages are executed in the same transaction. If there are more splits, a runtime error is thrown when the messages are committed in the JMS broker. The following scenarios split messages:
- Large Messages: If a message is bigger than 5MB, it is internally split into chunks before storing it in the JMS queue. This means if a 50MB message is received it is split in 10 chunks and so 10 messages are contained in one transaction. This means the message to store in a JMS queue must not exceed 1280MB (256*5MB).
- Splitter scenarios: If the original message is split into multiple split parts by the Splitter flow step you need to make sure not more than 256 split parts are created and stored in a JMS queue using the JMS receiver adapter. One workaround option for such a scenario would be to first split the message into bigger chunks using a Grouping in the Splitter and store the chunks in a first JMS queue (kind of intermediate queue). In a second process those bigger chunks could be split into single entities using a JMS sender adapter to read the chunks and store the single splits in the final JMS queue using JMS receiver adapter.
Size Limits for Messages, Headers, Properties and Attachments
The following size limits apply when saving messages to JMS queues.
- There maximum message size (including attachments) that can be stored in a JMS queue is 1280MB. See in last chapter for more details).
- Headers and exchange properties defined in the integration flow before the message is saved to queue must not exceed 4MB for headers and properties together.
Important: As mentioned, the size limits for payload and attachments are quite high, but you need to keep in mind that processing the message in the CPI runtime may limit the possible size of payload and attachments for your scenario. You as scenario developer have to test and restrict the limits your scenario can handle!
Hello Mandy,
thanks for the Blog. We just got the feedback from support that there is also a limit per queue (4GB). Is this still accurate or not?
Thanks and kind regards
Hello Richard,
yes, there also is a limit of 4GB on each queue. This value is not (yet) configurable.
I added this now also to the blog.
Best regards,
Mandy
Hello Mandy,
It seems that with the new capability to enable Enterprise Messaging within SAP CPI we have now two mechanisms to enable asynchronous queuing over JMS in SAP CPI:
For new SAP CPI customers with Enterprise Edition license, what is the SAP recommended option? What is the way forward? What are the Pros and Cons of each option?
Many thanks for your time.
Kind regards,
C.
Hello,
this is a misunderstaning. JMS Message broker and SAP Enterprise Messaging use exactly the same functionality underneath, this are no different options. Both us the same JMS message broker underneath.
CPI with Enterprise Editions uses Enterprise Messaging and if you want to increase the JMS limits you have to buy additional Enterprise Messaging units.
For non-enterprise licenses you can buy Enterprise Messaging separately.
BR,
Mandy
Many thanks for the clarification Mandy,
Reading the blog below, that did not become obvious to me.
https://blogs.sap.com/2018/12/12/cloud-integration-activating-and-managing-enterprise-messaging-capabilities-as2-jms-and-xi-adapters/
Thanks again.
Regards,
C.
Hi Mandy,
How to delete these queues where messages are in 'Retry' Status ?
I am having All authorizations(Administrator as well) but getting message like "Not Authorized to perform the operation".
Sender is AS2 and we have Enterprise Edition.
let me know how I can delete these queues.
Suresh
Hello Suresh,
usually with the Tenant Administrator role you would have the authorization to delete queues in the queue monitor.
BR,
Mandy
Mandy - Is there a way to set a specific JMS queue to by processed by one node only? We currently have two nodes which means that any OAUTH2 requests are being processed twice when there are multiple transactions being written to a JMS queue. I have the number of concurrent processes set to 1.
Hello Beverly,
a message is always only be processed once even if there are multiple worker nodes. If one worker node consumes the same message is not fetched by other workers. This is ensured. Once the message is consumed it is removed from the broker. Even if you have specified multiple concurrent processes it will not happen that multiple processes consume the same message. It just means that multiple different messages are processed in parallel.
So, probably there are multiple identical messages already stored in the queue?
Best regards
Mandy
For example, there are 20 messages in one specific JMS queue. Each message reads the database to determine if the Token has expired and if so requests a new OAuth2 token.
Message one determines that the saved token has expired and requests a new token and writes it to the database:
Message Processing Log:
StartTime = Thu Apr 29 06:00:28.732 UTC 2021
StopTime = Thu Apr 29 06:00:29.822 UTC 2021
But before Message one completes, Message two reads the token saved in the database and determines that it is expired and thus also requests a new token and write it to the database:
Message Processing Log:
StartTime = Thu Apr 29 06:00:28.724 UTC 2021
StopTime = Thu Apr 29 06:00:30.018 UTC 2021
My understanding is that this is due to having two nodes. I was wondering if there is a way to set a JMS queue to process under one node only.
I'm not really understanding the scenario. You start the scenario with JMS sender adapter and then do a http request to get a OAuth2 token and store this to a data store?
This means one JMS message would trigger the processing and if it ends with an error it depends on the transaction handling you specified if the entry in the data store would be retained or rolled back.
If you use JDBC transaction handler the transaction is rolled back and nothing is stored in the data store.
Or are you using JDBC adapter to store the token?
Regards
mandy
I used this blog to create my IFLOW:
https://blogs.sap.com/2016/12/28/hci-hcp-is-oauth-deciphered-retrieving-tokens-dynamically-initial-token-refresh-token-and-new-token-part-1/
Step 1- I save a copy of the original payload
Step 2 - Read the database for the token
If not found, request new token and write to database
If found determine if still valid - if not request new token and write to database
Step 3 - Restore original payload and continue with processing.
Hello,
as already mentioned the logic of storing and reading from data store depend on the configured transaction handling, see also this blog Cloud Integration – How to configure Transaction Handling in Integration Flow | SAP Blogs.
You need to carefully analyze what is happening in the integration flow, especially in case an error occurs. This depends on how the transaction handling is defined. A message is written either directly or within an E2E transaction at the end. I would suggest you do careful tracing of your whole processing.
Please understand that I cannot offer support for such complex problems here in this community blog. I can only ensure you that the JMS adapter ensures that a message is not processed twice even if multiple worker nodes are involved.
If you really think there is an issue with the JMS adapter, which I doubt, I would suggest to open a ticket on LOD-HCI-PI-RT.
Thank you,
Mandy
My apologies if I caused confusion. I wasn't saying that there was an issue with the JMS queues. I was just wondering if there was a way to prevent both nodes from processing a message from one JMS queue at the same time. In my example the queue contains 20 Invoice transactions which use OAuth2 and require a token for transmission. Node 1 selects one message to process, while node 2 selects a different message to process. What occurs is that before Node 1 can request a new token and write it, Node 2 has determined that the current Token has expired. I have the concurrent processes set to 1, which my understanding means that each node will process one message at a time, or in other words 2 messages can be processed at the same time. I'm trying to ask if there is a way to prevent the 2 messages from being processed as the same time.
Hi Beverly,
ok, now I got your question. No, this is not possible. All worker nodes start at least one consumer for the message queue.
Best regards
Mandy
Thank you!
Hi Mandy,
Does the same JMS limits apply even to CPI Runtime ( cloud integration content ) hosted on PO?
Also when you say limit of 150 transaction , what is a definition of a transaction , if I am using JMS in error retry exception subflow and suddenly because of some network issue there are 10, 000s of messages which needs reprocessing then how where does this 150 transaction limit kicks in .
Hello,
for the calculation of the transactions please check in the blog. There is a transaction required for each started consumer and for each running producer. If there are no transactions left at a certain point in time the processing would fail, meaning a message could not be stored to JMS or the consumers would not be able to consume a message.
For the on-premise PO runtime this is different as here an on-premise broker is connected: details see in 2577695 - JMS Messaging for Cloud Integration Content - SAP ONE Support Launchpad
Best regards
Mandy
Hi Mandy,
Thanks for the reply , from the SAP note I gather that there is no limit for CPI runtime ( cloud integration content) like CPI.
Also I can see that we can configure MQ , can I use JMS in CPI runtime for external MQ connection also?
So can I have interfaces connected to external MQ ? And not just use JMS for internal iflow processing ?
No, this is not possible in Cloud Integration's JMS adapter. The cloud integration JMS adapter always uses an internal broker.
Best regards
Mandy
Thanks Mandy,
Do you foresee this functionality getting added to CPI runtime anytime soon to connect to external broker like MQ anytime soon ?
Also the hybrid deployment due to release Q2 next year will it have this ability to connect to external broker like MQ?
Hello,
it is currently not on the short term roadmap, but as we get more such customer requests, this probably needs to be planned long-term.
Best regards
Mandy
Hello!
I have a trial account and set up a flow to receive a SOAP message and put it in the JMS queue......I'm getting the error when writing to the queue: java.lang.IllegalArgumentException: Session must not be null
Not possible for a trial account?
Thanks!
Hello,
JMS should also work for a trial account if you have provisioned the tenant with Message Queues.
Please check if the monitoring tile for Message Queues appears. If not, you have missed to activate the message queues. In this case go back to the provisioning and activate the message queues as described here: Integration Suite – Simplified Onboarding and Provisioning | SAP Blogs
Best regards
Mandy
The Manage Message Queues appears...the queues were created...but the messages aren't recorded in the queue....
Error Details:
java.lang.IllegalArgumentException: Session must not be null
Thanks
Ok, seems there is an issue when communicating to the broker.
I would suggest to open a ticket for this on LOD-HCI-PI-CON-SOAP
Best regards
Mandy
Hi Mandy,
Suddenly all JMS Queues disappeared from all our tenants. Cockpit is also not accessible. SAP CPI is fine, but the JMS is not available.
It looks like there is currently an issue with the JMS broker in the landscape. If such issues happen, best is to create a ticket.
Best regards
Mandy
Thanks Mandy, is it an issue with only our landscape. I see all our tenants dev, q, prod all have this issue.
Is it an issue with XXXXX-tmn.hci.eu1.hana.ondemand.com? Where can we find the status of the tenants. eclipse or cp status.io doesnt seem to show any!
Created a ticket with VH prioroty, but no response so far.
Hello,
I got the following information from our Ops colleagues:
We're currently having a region-wise issue that affects the Messaging Service on several tenants.
We work on the resolution on high priority and will notify you once issue is solved.
Best regards
Mandy
Thanks Mandy, is there any common url similar to CP-Status.io for these issues, just to update the clients.
In general, this page should also show such issues. I asked the colleagues to check why the outage is not reflected there.
Best regards
Mandy
Hi Mandy Krimmel,
We have also faced this issue of JMS resource not available. But after sometime, it is showing us- status of queue as critical in all our tenants. So, it is related to original quota issue or same as that of the previous one mentioned by you that something SAP is currently working on.
If the issue is related to queue size, please guide us in increasing it.
Regards,
Sindhuja.
Please refer to the linked blog on how to increase. This can be done via selfservice.
BR
Mandy
Hello Mandy Krimmel ,
Thanks for the detailed Blog.
I am seeing the below error at XI Sender Adapter, however the load is heavy i.e around 1k messages comes into every minute, total load of around 25k. Is this error due to heavy load ? Please guide me to solve this issue.
Hello,
this is an error we also saw at other customer tenants. The real root cause is still in analysis, but it seems to be related to high load. But I would still request you to open a ticket and provide the details like integration flow, message processing log ID.
Please open the ticket on LOD-HCI-PI-CON-SOAP.
Thank you,
Mandy
Hello Mandy,
Regarding the above mentioned issue, do we have any fix yet ? You mentioned the root cause is still in analysis. Can you please confirm if this issue is resolved?
Thanks,
Punith.
The issue should be already solved. Do you still have such issues in your tenant? If so, I would request you to open a ticket.
Best regards
Mandy
Hello Mandy,
Thanks you for valuable information.
I am new to CPI using your blogs I am trying to build producer consumer flows with custom retry mechanism in consumer flow. I wanted to use a single JMS queue for all the flows that we build in CPI dev tenant. Can you suggest how to implement this. Do i have build custom modification in the flow or router can help here.
for example : The common queue receives Delivery XMLs or IDocs or any other data in XML format. We want to route the related XML to related consumer flow. How to achieve this?
Can you please help.
Thanks in advance.
Hello,
this would only be possible with a router in the JMS consumer flow as you somehow have to distribute the documents to different receivers. I could imagine that one flow with JMS sender and a router to different receivers (maybe even decoupled in different flows via Process Direct Adapter) would be the best solution.
Best regards
Mandy
Hi Mandy,
not sure this is the right place to ask, but I though I give it a try. For a customer with Integration Suite on Cloud Foundry (Standard Edition) and message based metric...
Many thanks and kind regards
Jens
Hello Jens,
let me answer your questions:
Best regards
Mandy
Thanks Mandy, very (very) helpful 🙂
one additional question though (hope you don't mind)
If we would reach the limitations, e.g. when exceeding the consumers (am I right in the assumption that one AS2 receiver channel would be one consumer?), you and help said, one could increase the "Enterprise Messaging" capabilities in self service. Now Enterprise Messaging, as already said, is a term of the Neo environment (at least that is what I figured). Also the linked blog https://blogs.sap.com/2018/12/12/cloud-integration-activating-and-managing-enterprise-messaging-capabilities-as2-jms-and-xi-adapters/ deals with Neo
Many thanks again and cheers
Jens
Hi Jens Schwendemann
did you receive an answer to your points? I am asking myself exactly the same question, today in SAP PI i have configured per Business Partner one AS2 Sender Channel where i have created an dedicated endpoint to get data from this Company (e.g. https://host:port/AS2/Company1, https://host:port/AS2/Company2). Reason for that is, that we have based on the URL string an IP whitelisting on our firewall.
Now with Cloud Integration we are no longer behind a firewall. So the Endpoint is always accessible for all Partners - however, now I have to grant them a user, as of my observation, no anonymous AS2 is possible.
What is now the correct approach? One iFlow for all AS2 inbound - persist to the Queue and catch them based on AS2ID or UNB Information using "Process Direct" to individual iflows? Or continue like in the past by creating one AS2 Sender Flow per Company - but how to influence that i don't run out of Queues?
BR Helmut
Hello Mandy Krimmel
we will use JMS Queues for ErrorHandling.
Now we will may have the situation, that we have to restart the whole tenant.
Can you please clearify, if the data in the JMS Queue are cleared/deleted after the restart ?
Best Regards
Hi,
messages in the queues are retained during updates/restarts of the tenant as they are persisted in the queues. They only get removed if successfully processed.
BR
Mandy
Hi Mandy Krimmel, Can we connect to the JSM Broker from an external application (Application from internet outside BPT) to consume messages generated by iFlows or publish messages to a queue so that iFlows can process them?
Hi Anil, does this answer your question? https://blogs.sap.com/2017/10/04/cloud-integration-jms-resource-and-size-limits-in-cpi-enterprise-edition/comment-page-1/#comment-582971
Regards Marco
Hi Marco,
I am looking for connecting to external JMS Message Broker using JMS Adapter.
I want to know how to connect to Internal JMS Message Broker from External application like Java or Python.
I don't see Server URL and credentials of the Internal JMS Message Broker anywhere.
Thanks
Anil
I got answer to this at https://answers.sap.com/questions/13909169/connecting-to-jsm-broker-from-external-apps.html.
Basically, internal queues can't be accessed from external directly.
Thanks
Anil
not via the JMS adapter. The current JMS adapter is purely used for writing and consuming within Cloud Integration.
You would have to go for the AMQP adapter to fetch messages written by another application: Cloud Integration – Connecting to Messaging Systems using the AMQP Adapter | SAP Blogs
Best regards
Mandy
Hi Mandy,
Thanks for the blog.
At our client, we have Integration Suite ( Enterprise Edition) on cloud foundry where we have run into issues with exhaustion of maximum number of transactions and SAP support has referred us to this blog for increasing number of JMS queues. I see that you have provided reference to the the blog Cloud Integration- Activating and Managing Enterprise Messaging Capabilities ( AS2, JMS and XI Adapters ) in Neo | SAP Blogs for increasing JMS resources but it seems valid for NEO.
Could you please point us to a help doc for increasing JMS resources in Cloud Foundry ?
Thanks & Regards,
Satyaki
Hi Satyaki,
in the Integration Suite Home you can manage the capabilities: Activating and Managing Capabilities | SAP Help Portal. Using Edit you can increase the message queues for your tenant up to 100 as a self-service. If you need more queues open a ticket as described in this note: https://launchpad.support.sap.com/#/notes/3318666.
Best regards
Mandy
Thanks a lot Mandy for the quick help 🙂
Hi Mandy,
We are facing this below error in CPI
(MasterData_TaOECC_SplitByMessage) thread #4743 - JmsConsumer[TaOECC_SF_MasterData]#com.sap.it.commons.logging.slf4j#na#na#na#na#[][Logging.groovy][processData]:Header 'SAPJMSRetries' does not exist
Below is the configuration
Could you please suggest if we are missing something
Or something can be implemented.
Thanks in advance
Regards,
Sahil Khumman
JMS Queue Configuration