| Author |
Message
|
| Lichking1234 |
 Posted: Mon Sep 29, 2014 1:43 am Post subject: ''resetMessageDomain.internal_npcompiler'' not valid |
 |
|
Newbie
Joined: 29 Sep 2014
Posts: 5
|
Broker throws the following error ''resetMessageDomain.internal_npcompiler'' not valid for target object, while deploying a .bar file with a compiled message flow(.cmf file) which has a subflow using the ResetContentDescriptor node.
Same flow when built into a bar without compilation is working fine.
Using IBM Integration Bus 9.0.0.1 and Integration Toolkit 9.0.0.1.
Thanks in advance. |
|
| Back to top |
|
 |
| Vitor |
| Posted: Mon Sep 29, 2014 2:53 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Ok, that 2 people post this message at once is an odd concincidence at best!
At least you included version details and a scenario.
Perhaps something about how subflows are handled in IIB is a clue. Especially something that you can do (which is a default) in a bar file build that you can't on a generated bar file.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Lichking1234 |
| Posted: Mon Sep 29, 2014 3:51 am Post subject: |
|
|
Newbie
Joined: 29 Sep 2014
Posts: 5
|
Hi Vitor, thanks for your reply.
From what I could comprehend of the error message, it seems like the compiled code generated by mqsicreatebar has a property which the broker runtime is unable to identify?? I have added the complete Error Trace below.
"The message broker received a configuration message containing the attribute name 'resetMessageDomain.internal_npcompiler' which is not valid for the target object. This can be caused by a mismatch in levels between the Integration Toolkit and the broker, or as a result of a user or third party written user-defined node where the implementation library installed at the broker does not match the node definition held at the Integration Toolkit.
Ensure that the levels of code installed at the Integration Toolkit and broker are consistent. If they are, identify the supplier of the target object and report the problem to them. If this is IBM, contact your IBM support center."
Considering that both the runtime and the toolkit are at the same version, this shouldn't be a problem, unless there is an update required to either of the two (just guessing here)
And it seems like the parallel thread is from a colleague of mine at a different location.  |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Sep 29, 2014 4:27 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20697
Location: LI,NY
|
| Lichking1234 wrote: |
"The message broker received a configuration message containing the attribute name 'resetMessageDomain.internal_npcompiler' which is not valid for the target object.
|
Considering that this is the IBM standard (so none of the subsequent info may apply) have you made sure that the above condition is correct?
In other words do you have the reset domain flag set on the RCD node and not specified a valid domain? (like DataObject without the means to transform to a DataObject) 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Lichking1234 |
| Posted: Mon Sep 29, 2014 4:49 am Post subject: |
|
|
Newbie
Joined: 29 Sep 2014
Posts: 5
|
| fjb_saper wrote: |
In other words do you have the reset domain flag set on the RCD node and not specified a valid domain? (like DataObject without the means to transform to a DataObject) |
The reset domain flag is set to true and the domain specified is DFDL.
Note: Since the RCD is used within the sub-flow, all its properties are promoted to the main flow and the values are set in the main flow. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Sep 30, 2014 2:46 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Lichking1234 wrote: |
| From what I could comprehend of the error message, it seems like the compiled code generated by mqsicreatebar has a property which the broker runtime is unable to identify?? I have added the complete Error Trace below. |
By combining the information on these 2 threads, I continue to believe this is a difference between the way the mqsicreatebar & mqsipackagebar are dealing with the sub flows; especially given that there are 2 user selectable ways this can be done, and you have promoted properties in the RCD which is non standard.
Seriously - why would you change the values of an RCD at deploy time? If you have the possibilities to have multiple domains at run time, do it in code.
You might be able to work round it by using the same options (explicitly or implicitly) in the mqsicreatebar as in the mqsipackagebar, but as my worthy associate points out, an IBM supplied object shouldn't come up as unknown and it's time for a PMR.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Lichking1234 |
| Posted: Tue Sep 30, 2014 3:51 am Post subject: |
|
|
Newbie
Joined: 29 Sep 2014
Posts: 5
|
| Vitor wrote: |
Seriously - why would you change the values of an RCD at deploy time? If you have the possibilities to have multiple domains at run time, do it in code.
|
Hi Vitor, we are not actually promoting the value all the way to change the domain at run time, just promoting from the sub-flow till the main flow to set the value from the main flow. The reason for this approach is to bundle a bunch of re-usable logic into the sub-flow, while leaving the developer of the main-flow the choice of re-parsing the message into the domain of choice without having to open the sub-flow. Not sure if this is the right approach though
| Vitor wrote: |
You might be able to work round it by using the same options (explicitly or implicitly) in the mqsicreatebar as in the mqsipackagebar
|
Just to add to that, the difference in behavior is observed with just mqsicreatebar with -deployAsSource enabled and disabled. The flow builds fine and deploys while using the -deployAsSource, whereas causes the mentioned issue when not used with -deployAsSource. Leaving out mqsipackagebar for now.
| Vitor wrote: |
as my worthy associate points out, an IBM supplied object shouldn't come up as unknown and it's time for a PMR.
|
Cheers  , lets see what IBM has to say regarding this |
|
| Back to top |
|
|
|
|
