xMII 12.0 SP2 message rules issues

[Former Member]

I'm running xMII 12.0 SP2 on NW 7.0 SP13 and I have some questions and comments.

1. In the Message Processing Rules - Parameters section, what does the "Value" mean? And why does it have to be set to "ReceivedMessageXML" for the "Name" checkbox to remain checked? Is this some internal xMII parameter name which the message processor uses to map the input parameter? It it must be "ReceivedMessageXML" why have it at all? Are there other valid Values?

2. Also in Message Processing Rules, there are some strange browser issues. In IE 7, if you create a new Rule all the fields are cleared and server name defaults to the first choice in the combo. If you look at the Message Type radio buttons, the IDOC button is missing. You have to select a transaction before the button appears. This doesn't occur in Firefox 2.0

3. Still in Message Processing Rules with Firefox 2.0, when you click "New" rule, the category/transaction fields remain from the previous rule (depending on whether the previous rule was a category or transaction type rule). In IE 7, clicking "New" clears those fields.

4. There's a browser issues in the portal too. It works fine in IE 7, which is likely the officially supported browser, but in Firefox 2.0, the the top level portal items cannot be expanded to show their contents. I'm guessing Firefox is not a supported browser...

5. We ran the latest migration tool against our 11.5 code - approximately 70 transactions, a couple dozen irpts, javascript, images, 100 or so query templates and a smattering of display templates and it worked flawlessly. I noticed that the migrated IDOC listener rules are named "Rule 1", "Rule 2", etc. However, you cannot save rules with spaces in their names. Is this intentional? We copied/renamed them all anyway to match our naming scheme.

6. Does the xMII Best Practices document address naming conventions of some of these new xMII 12.0 features? e.g. should message rule names have the company name as a prefix such as "Visiprise_DMO100_MATMAS"?

Thanks much!

-tim

[salvatore_castro · Accepted solution]

Tim,

With regards to posting comment #6, there are no specific naming convention recommendations pertaining to the message listeners in general for v12. The only thing to consider for these is common sense, you don't want to give it an ambiguous name and you don't want to call the listener and rule the same thing but you do want their names to be related. Also be sure to include verbose descriptions of each component.

Pretty sure that this is what you would do anyway but wanted to make it clear for others reading this post.

Sam

[Former Member]

requesting an answer to my follow-up question

[former_member193328]

Hi Tim

Regarding 2.

New will clear all fields and default the dropdown to the first server in the list. If you want to retain entries from an existing entry while creating a new one choose Copy. It will keep all details and allow you to change only the relevant fields.

Regarding problem with Firefox 2.0 this browser is not supported by xMII and hence should not be used.

I cant recreate the problem mentioned for IE7 when I test it on mys system.

Regards

Partha

[erik_schrampf]

Tim,

I think this would be a good case to enter a case into support. When the answers found we can post back the results here.

Erik

[Former Member]

Thanks, Erik. A service message has been sent. It includes a new one we just discovered: the xMII engine logged our user's password in cleartext.

-tim

[former_member193328]

Hi Tim

Regarding 1.

The Parameters sec lists the input parameters for the transaction selected to be run by this rule on receiving of a RFC/IDoc/Http message.

Now as this transaction needs to be run it can be assumed that the user might need to pass the received xml message (and this is where the name "ReceivedMessageXML" comes from) to this transaction. So if u select the check box against one or more transaction input params the actual message received will be passed on to these params. Needless to mention that the input param needs to be of type xml. The text ReceivedMessageXML is just an indicator/place holder for the actual xml.

Other valid values can be any string that u might want to pass on to other params of the trx. U just need to type them in the value field and not check the checkbox against their name.

Hope this clarifies the problem.

Regards

Partha

[Former Member]

Partha, thanks for the response. If you have a minute, I have a few more questions/comments:

1. Are there other input message parameters available besides "ReceivedMessageXML"?

2. If not, and you can only send in the "ReceivedMessageXML", why do you need to set the Value column to "ReceivedMessageXML"? Isn't the checkbox enough to indicate which transaction input parameter you want the message XML mapped to?

3. you say "if u select the check box against one or more transaction input params..." - why would you ever select more than one? Isn't the entire message payload going to be sent as an XML type parameter?

4. I like the idea of being able to set other input parameter values from the message rule. The trick is to not check their checkbox, right?

Thanks,

-tim

[former_member193328]

Hi tim

Sorry in the delay in response.

1. There are other input params available as well. Actually all input params of the Transaction will be listed here. The checked one is the one that will get the incoming message.

2. Yes it is. It is just to tell users that this param will receive it. Kind of a help. U may not check the param and type in ur entry on this screen as well.

3. Ideally no but if u want u can do that.

4. Yes dont select and type in ur entry.

Hope this helps.

Best regards

Partha