[community-content]

Thanks Stephen,

I couldn't find much about this, but I ended up spending several more hours on it and messed with using a property schema on a 'dummy' field I placed in the schema that will never be populated by the source application.  Based on a value in the incoming message, I read for that value and place it in the dummy field and promote it and that seems to work the way I want it to, to a degree, but I still can't come up with any ideas on how I can make the messages unique enough to a point where I can use maps to do my transformations.  I'm using a LOT of Xpath to create the outgoing messages and I was hoping to get rid of most of it.

Thanks!
-Rich

 

[community-content]

Have tried a few things, and nothing seems to work.

The schema that I receive has a date in it, format is <Datum>2007-02-21</Datum> and type is xs:date.

How to check this in the Business Rule Engine and let the BRE change a boolean if date is more than 26 weeks (182 days) from SysDate.

Any help will be appreciated.

[community-content]

thanks tomasr for your reply,

now i feel that i am in big trouble. the project that i am working at forces me (according to the client internal system) to have many messages with the same root node and with empty target namespaces (same message type). so how do i overcome this in my scenario?

[community-content]

Thanks for the replys. It works now. As you said i forgot the root element name and there was a space behind the namespace of the property…

[community-content]

Can you have the messages received by different receive locations?  If so, you can use the Schema Collection properties to set the exact message for each pipeline. 

 

Or maybe set the pipeline to allow unrecognized messages and cast the message into the correct type (or set message type – although I think it’s read only) inside an Orchestration?

 

Just some ideas.

 

[community-content]

You seem to be promoting only the namespace but not the root element name…. remember the MessageType is formed namespace#root

[community-content]

Julian,

Recently I had the same error you received. In my case I received a flat file which I transformed to XML in a custom pipeline. However I forgot to promote the MessageType to the Message Context, resulting in the 'no subscription found' error.

Promoting the MessageType tot the message context fixed the error. The code of the Execute-method in your custom pipeline component will look as follows:

public IBaseMessage Execute(IPipelineContext pContext, IBaseMessage pInMsg)
{
   string systemPropertiesNamespace = @"http://schemas.microsoft.com/BizTalk/2003/system-properties";
   string _XMLMessageType = @"http://BizTalk2004TestProjects.ReceiveEmptyFile.EmptyFile#EmptyFile";
   pInMsg.Context.Promote("MessageType", systemPropertiesNamespace, _XMLMessageType);

   return pInMsg;
}

Good luck,
Lex

 

[community-content]

I must have been brain-dead at the moment.  Solved this by simply taking a formatted text file and generated a schema for it using the wonderful wizard.

– Tomas

[community-content]

context.Promote("MessageType", "http://schemas.microsoft.com/BizTalk/2003/system-properties ", "http://ClaimSchemas.s_ExcelContract")

"MessageType", "http://schemas.microsoft.com/BizTalk/2003/system-properties ", "http://ClaimSchemas.s_ExcelContract")

if this is promoting the MessageType correctly then it does. Otherwise i would be thankful for a little hint how to do it correctly

[community-content]

If your message is getting a routing failure, it means the pipeline is working as intented: The message is getting through to the message box, but because there was a conflict and the disassembler wasn't able to figure out the message type, it doesn't promote the MessageType property into the message context, necessary for typed subscriptions from orchestrations to work.

 

[community-content]

Is your custom disassembler correctly promoting the MessageType property? Most regular subscriptions (such as typed subscriptions from orchestrations) depend on that property being there correctly set up (the XmlDisassembler and FFDisassembler do it by defauult).

[community-content]

I suppose yes.

From long term point of view SSODB is best option to go for.

[community-content]

[quote user="NISHIL"]

But according to Grondal's current Scenario , he just wants to access one URL from all Orchestrations so BtsntSvc is better.

[/quote]

Hi Guys,

You are correct that I only want to access the one value at this point in time. However, I suspect that over time I am going to need to store extra values as Glenno suggested. Are you suggesting that SSO is the way to go long term?
 

[community-content]

Glenno,

From future compatibility point of view SSODB is any day better as it can encrpty our key/value pairs and we just need to store them in a single Central SSODB database.

But according to Grondal's current Scenario , he just wants to access one URL from all Orchestrations so BtsntSvc is better.

Also every Biztalk Developer knows where BtsntSvc.exe.config is located …anybody can search it thru Windows File Search Tool.

[community-content]

That sounds great for one config value; but what about when in further iterations of the application more config values need to be added, are you going to add them all to the config file?

 Also the config file provides no visibility without finding the file and opening it.

[Author]

Posts