webMethods integration server accessing via load balancer and on two servers Integration server is installed. clustering not configured.
Integration publishes document with JDBC Basic notification and only one server is always getting request and processing though two IS servers are present. How can I ensure multiple transactions are picked up by both IS servers parallelly. i.e let’s say 1000 published documents needs to be processed by IS servers, load should be segregated between both of the IS nodes. but, always only one server is picking up published documents and processes.
I went through the documentation and i understand that clustering can be configured in IS but that needs another product to be licensed. for example: terracotta.
Is there any other way, without Terracota clustering can be achieved i.e both servers can be utilized to process transactions OR it’s via Universal messaging it can be achieved.
That doesn’t sound right. Long ago I needed to do the opposite(only one IS supposed to consume the message at any given time) of what you need, back then it wasn’t supported (v9.6). Does concurrent processing do the same? It is in the trigger properties panel.
Can you verify both of your ISs UM connections? Normally weather you configure internal clustering or not they are basic subscribers, if you configure durable subscriber they should act as single subscriber and both should consume messages. If there is no connection problem then that must be because of a configuration in the trigger properties.
If everything is as it is supposed to be, check the message acknowledge settings in the trigger. If using XA transaction with the trigger and don’t need it, try to disable it.
notifications set to concurrent on both the nodes.
here’s trigger configuration properties and as you can see its concurrent. however, i am not seeing XA Transactions property with the trigger.
the document link that is provided is consuming JMS messages concurrently in load balanced fashion. whereas, webmethod messaging provider connect is local connection and not using either UMS or JMS providers.
what is recommended approach to enable multiple nodes processing transactions.
Load Balancer is typically for incoming network traffic on an HTTP/S port, wherein those requests will be distributed according to the balancing principle, such as Round-Robin.
For JDBC Notifications, you need a Messaging Provider such as Broker or UM, or a third-party messaging product that supports a messaging standard, say, JMS. Your ISes must be connected to this provider to send and receive messages.
You seem to be expecting a LOCALLY published Notification document on IS1, to be picked up by another IS2, without any Messaging subsystem between them. This is similar to me sending a post to my own address and expecting it to arrive at my neighbour’s house.
It’s either this or I’m terribly misunderstanding your landscape.
Can you elaborate what you mean here?
“the document link that is provided is consuming JMS messages concurrently in load balanced fashion”
Note - Terracotta BigMemory for Clustering purposes only should be available with your IS licence. You can check this with your Licence Manifest or ask your Software AG Account Executive or open a Support Ticket to get a clarification.
Please add a screenshot of your connection allies. You can find which one it is using from the trigger and you can find its configuration details from IS admin UI.
I am still not clear about what you are trying to do. Do you have an adapter notification or are you just consuming messages from queue/channel/document ? They might look similar but they are not.
edit: Somehow I missed one of your messages. This seems to be your problem.
This may be the issue. Local connections do not leave the IS on which the document is published. They are handled locally – as @Venkata_Kasi_Viswanath_Mugada1 noted earlier.
Can you share the doc type definition?
Side note: we avoid JMS. More administrative overhead than using wM messaging with UM. Of course you may need to support it if other applications are communicating with wM IS via JMS. But in this case, since the DB notification and the dispatching of record processing is all handled by wM components, no real reason to use JMS.
you are right and agree. it was getting published locally and thinking both nodes will pickup since same trigger messaging is configured on both the nodes.
Licensing is as follows. does this mean, separate terracotta array licensing is required.
Thanks for response. document type is xml. it is not complex EDI document. pointed noted on JMS. now to enable clustering i understand that, terracota array can be used. but, wondering where exactly WM Messaging with UM is required. what i understand is, instead publishing messages locally, it can be published to Universal messaging for guaranteed delivery and to ensure either of servers pick up messages cluster can be configured/documents can be queued up using terracota server array. pls correct if this understanding is incorrect @Reamon and @Venkata_Kasi_Viswanath_Mugada1
I am assuming terracota array licensing is different and UM license is different?
The licensing screenshot above is only for the IS capabilities. Yes, the licences are different for each product. In addition, each product has multiple variants of the licensed capabilities and combinations depending on the product codes, which is why I had said the following -
check this with your Licence Manifest or ask your Software AG Account Executive or open a Support Ticket to get a clarification
Everything that you need is in the documentation (more than what I have listed below) -
There’s a lot of documentation available on our site (link).
A ton of public training content is available here (link) - you can apply your filters for versions.
For this task, IS clustering using Terracotta is not a factor. It is not needed for this and if it is present, is not used for this.
IS clustering is one of the most misunderstood items. The scope of functions to which it applies is far more narrow than people think. For messaging, it does not apply at all. Review the cluster documentation to see the scenarios in which it applies. There are old threads in the forums that may be of interest. One of the threads advocates for not using/needing IS clustering in general. It may be useful/necessary in a given environment but for the most part, it is not IME.
Sorry for the confusion. Was asking for the IS doc type info, mainly the properties pane to see what provider it is associated with.
IMO, don’t use JMS and no need for clustering for this. Use wM messaging with UM provider. It will do what is needed for this in the simplest way. Using a JMS provider will require more administrivia than using a UM provider.
EDIT: In your OP you asked:
It is via UM that you can do what you described for all IS nodes in the “messaging cluster” (not IS cluster/Terracotta cluster) to process messages from the durable subscriber in parallel, with each message being processed just once.
Just wanted to add that a document type is NOT xml. It is completely agnostic and allows the developer to map/query/transforms Document instances without having to worry about specific formats. We also provide simple services to allow them to converted to different formats when communicating with external clients such as XML, but just as easily also from/to JSON. For formats where there is no explicit structure then you can create a flat file schema to transforms.
The idea is that you don’t have to duplicate business logic or functional services just to change the format for one client app or another.
regards,
John.
