Currently, we have 4 production webMethods Integration Servers (HOEWIS82/83/84/85 running IS 6.0.1 SP2) configured as a single webMethods Cluster. All these 4 production servers are connected to the same webMethods Trading Networks Database (via Setttings -> JDBC Pools)

We are planning to add a new production webMethods Integration Server (but not configured in the same Clusters).

Question:

1. Can the New production webMethods I.S. connects to the same webMethods TN Database (Oracle-based)

Thanks in advance for your reply

Yes, you can

Ramesh

Thanks for your reply.

Actually, I have submitted a SR to webMethods, but webMethods said
it will violate their support policy if we go ahead with this
configuration

Stephen

Stephen,

Are you talking about having both the clustered servers and the non-clustered server share the same TN DB – meaning using the same schema? That sounds like invitation for trouble. Especially for Production system…

Why would there be trouble? The data stored within the TN tables doesn’t care about the cluster configuration of IS in any way. Pointing to the same DB and setting the TN config on each instance so that TN item changes and TN property changes are sync’d amongst the instances is all that is required. Inclusion/exclusion within an IS cluster has no impact AFAIK.

And I’m not sure why wM wouldn’t support this configuration, but I guess if you do run into any issues, you’ll need to be able to duplicate any problem in what wM considers a “homogeneous” environment.

Thought of an case where having an IS instance connected to the “TN cluster” but not to the IS cluster can be a problem.

When using public queues, TN Console creates a scheduled task. If this task is not marked to run in the IS cluster, which I don’t believe can be set using TN Console, it will run on multiple servers. In Stephen’s case, the scheduled task will run on one of the IS cluster instances and also on the instance that is not in the IS cluster. This may or may not be an issue for Stephen’s specific needs.

HTH

Some Service Packs (or Fixes even) involve altering DB schema, so there’s two concerns:

1. Need to shutdown everything to upgrade the DB schema
2. Make sure all the servers have the same SPs/Fixes applied – Something you needed to do with the clustered machines anyway.

What kinds of problems would there be when sharing TN DB between servers? In Stephen’s scenario, we can simplify the problem to having two IS sharing TN DB concurrently – I’m thinking of the cluster as a single IS, with a major difference that the clustered systems will be connected via Broker, the lone system may or may not.

When a doc is submitted to TN (at least for RosettaNet), the doc is published after recognition and persistence. What then?

It seems to me that if both sides are connected via Broker, Models could be kicked off on both sides. And in a multi-doc transaction (like RN PIP 3A4 PO Request), you could get multiple response docs to the same incoming request.

Or, as Rob pointed out, task scheduling would be a mess, if the two sides are meant to share pretty much the same work.

What happens when you have both sides doing polling notifications (i.e. JDBC adapter). My head aches just thinking about this… 8|

If both sides are not meant to be joined that tightly, I could still see some trouble in daily operations though. Docs received/processed on the other side would just pop up magically in Transaction analysis, but its processing status (WmMonitor) would only be available on one side. Definitely freaky…

What all this boils down to is that I don’t know Stephen’s rationale for having such a configuration. It might be okay for certain usage, but my point is that it’s not suitable for general usage. Almost like having clustered servers w/o clustering being set up…

We may be reading too much into Stephen’s question. He may just want to know if a stand-alone IS/TN instance can use the cluster’s TN DB tables. The short answer is yes. This would allow the stand-alone instance to use existing profiles, rules, doc types, etc.

There are some caveats though. In this case, you’re setting up what amounts to a “TN cluster.” In a TN cluster, all instances use the same DB and are configured to share TN properties file changes and notify each other when TN elements (profiles, rules, etc.) change.

If that’s all that’s being done, then you’re probably okay.

However, because your IS cluster and your TN cluster don’t fully match each other, you’ll need to be aware of some things. You’ll need to fully understand the implications of how documents are processed, published and subscribed if there is any “cross-talk” between the two different types of clusters. If a Broker is involved and models are triggered by TN documents, then you’ll be better off keeping the stand-alone instance completely separate.

Keep in mind that the use of Broker and the use of IS cluster are independent things. The use of one does not imply the use of the other.

HTH