TN user status randomly updates to IGNORED b/c the default rule gets selected

, ,
1

We are running on TN 6.1. We had a partner setup using an EDI ID of another partner that is currently not on WM TN yet and the partner that is in TN migrated last December. Now we are working on migrating the “other” partner into TN but the problem is that you can not have two partners with the same DUNS number setup in TN. So we decided to take the existing partner in TN and make it the new partner we are migrating into TN and then create a new partner setup for the old partner that was migrated last December. So Recently I have migrated the new partner and the modified partner in TN and at the same time had to modified the existing EDITPA’s and custom processing rules to match the new partner instead the old partner that I had updated because the modified partner will be used with a different set of processing rules. We also have a default processing rule setup to catch any unknown’s and we update the user status to “IGNORED”. Before I made the changes I never had a problem with the custom processing rules or the default rule. But since I have made changes, randomly the “default” rule gets selected instead of the custom processing rules. I can not figure out why only sometimes TN selects to use the default rule and the other times it selects the right custom processing rules. I am wondering if it had to do with the changes I made and how I made them? Also has anyone ever seen this before and have a solution to it?

2

Is the “Default rule” sitting very bottom in the processing rules page?? If not shift it down to last and make sure your custom processing rule is above it and enabled.

HTH,
RMG

3

Yes the default rule is at the very bottom and the custom processing rules are enabled.

4

“I can not figure out why only sometimes TN selects to use the default rule and the other times it selects the right custom processing rules”

When default rule is recognized is everything got recognized triplet(Sender/Receiver/Doctype)?? Are you seeing any errors in the Actvitylog or IS logs?? Are you seeing any differences in the payload/recognition when the right custom rule is triggered?

HTH,
RMG

5

Yes everything SIZE=1 is getting recongized and the correct sender which is the key that TN uses to select the custom processing rule is there and is the correct one. I went as far as looking into the database itself and there is nothing out of the ordinary. The activity log is showing no errors. All I get from the activity log is that the default rule was selected and the user status is updated to “IGNORED”. I am thinking there is an issue between the two servers. I know that even though we have 2 IS for prod, both read from the same database so I wouldn;t that migrating the profiles to prod would be an issue for either IS. I did notice though when I went into TN console for IS1 that the profiles acted normal but when I went into TN console for IS2 and I tried selecting the newly created profile from the transaction analysis it brought back a blank and then when I went to the modified profile and selected it, it brought back the other profile. Is it possible that cache is off between the two servers?[/size]

6

TN caches the data it reads from its database. It refreshes when: 1) a change is made using TN Console; 2) another TN instance tells it to refresh its cache.

That you have 2 IS/TN instances was an important piece of information. You need to configure each instance to notify the other when the DB changes (profile, doc type, rule, TPA changes). Otherwise, one server will behave “correctly” and the other will be confused because it is working with outdated config data. Refer to the TN docs and help.

7

Thank you for the response. I was starting to lean towards the two TN instances not matching and one having an older config data. This is a good piece to keep in mind.

8

I do have a question…we are configured for a cluster enviroment so is there some other TN specific setting outside of the configured cluster that we need to do?

9

Which type of “cluster” are you using? There are several that are possible:

  • IS cluster–this is where two or more IS instances share a common repository. This cluster doesn’t affect TN directly.

  • Broker client cluster–two or more IS instances connect use the same Broker client prefix to connect to the same broker client queues. IS clustering is not required to do this. This cluster doesn’t affect TN directly.

  • Load balancing cluster–two or more IS instances are grouped using an external load balancer, such as BigIP or a Cisco device. IS clustering is not required to do this. This cluster doesn’t affect TN directly.

  • TN cluster–two or more TN instances (on their respective IS instances) share a common database and are configured to notify each other when config items change. Once again, IS clustering is not required to do this and is actually completely independent of IS clustering. If you have an IS cluster, you typically should set up a TN cluster.

  • OS cluster–typically used for Broker to provide an active/passive cluster, but it can be used for IS as well (though it isn’t officially supported).

There are indeed a few TN configuration items that you’ll want to set. Look in the TN User’s Guide for the tn.cluster properties.