BizTalk Server Schema Editor getting blocked by Internet Explorer Enhanced Security Configuration

BizTalk Server Schema Editor getting blocked by Internet Explorer Enhanced Security Configuration

I have been working on a new BizTalk Server project on a new client for a few weeks. Now that we are beginning the development phase, I was getting annoying with an Internet Explorer security blocking windows every time I try to open a schema document on Visual Studio with the BizTalk Server Schema Editor:

Internet Explorer

Content within this application coming from the website listed below is being blocked by Internet Explorer Enhanced Security Configuration:

about:security_devenv.exe

To be honest, I initially ignored this issue and immediately clicked on the Close button, and everything would work as usual. But starting to work every day on the project and facing this issue every time I tried to open a Schema was simple to annoying.

Cause

We don’t need the IE to develop BizTalk Schemas, but the XSD viewer, in fact, opens an IE embedded inside Visual Studio. And that is the reason for this issue.

I typically don’t get this “warning” message because I usually turn off Internet Explorer Enhanced Security Configuration on my BizTalk Servers.

Solution

The solution is simple:

  • You can turn off Internet Explorer Enhanced Security Configuration by:
    • Start by running the Server Manager, if it is not already open, from either:
      • On the Windows taskbar, click the Server Manager button
      • On the Start screen, click Server Manager
    • In the Server Manager Dashboard, from the scope pane (on the left side) click on Local Server
    • In the Server Properties for the Local Server, you’ll see the option for IE Enhanced Security Configuration. Click On to change the option
    • A dialog box appears, letting Internet Explorer Enhanced Security Configuration be enabled/disabled separately for normal users and administrators; turn off both. After disabling both options, click OK
    • Click the Refresh button at the top of the Server Manager and the IE Enhanced Security Configuration should now show as Off
  • Or, if don’t want to turn off Internet Explorer Enhanced Security Configuration , you can on the blocking pop-up window click on Add
    • On the Trusted sites window, make sure Require server verification (https:) for all sites in this zone is not marked and then click Add

After one of these two options/settings that annoying blocking behavior inside Visual Studio will be gone.

The post BizTalk Server Schema Editor getting blocked by Internet Explorer Enhanced Security Configuration appeared first on SANDRO PEREIRA BIZTALK BLOG.

Demystify Invalid type name error on BizTalk Schemas (Part II)

Demystify Invalid type name error on BizTalk Schemas (Part II)

In the last post, we try to demystify the reason and cause of the error: Invalid type name. The root node type has to be a valid C# identifier when you are working with a schema with a single root node.

In this second part of the post, we will address what happens If we are working with a schema with multiple root nodes, and two or more root nodes contains hyphens (-) or any other punctuation characters?

Let’s take the following example, where we have:

  • The root node “My-NAME-SANDRO” with the “RootNode TypeName” property set as “My-NAME-SANDRO”
  • And the root node “Let-SEE-What-happens” with the “RootNode TypeName” property set as “Let-SEE-What-happens”

BizTalk Schema: Invalid type name error

If we try to build our BizTalk Server solution within Visual Studio it will fail with the following errors:

Severity Code Description Project File Line Suppression State
Error Node “My-NAME-SANDRO” – Specify a valid .NET type name for this root node. The current .NET type name of this root node is invalid (it is a reserved BizTalk Keyword or is an invalid C# identifier). c:users…documentsvisual studio 2015ProjectsBizTalk Server Project1BizTalk Server Project1Schema2.xsd 1
Error Node “Let-SEE-What-happens” – Specify a valid .NET type name for this root node. The current .NET type name of this root node is invalid (it is a reserved BizTalk Keyword or is an invalid C# identifier). c:users…documentsvisual studio 2015ProjectsBizTalk Server Project1BizTalk Server Project1Schema2.xsd 1

BizTalk Schema: Invalid type name errors

Cause

Official Microsoft documentation state that The Type Name property of this schema file is not valid. Because the value of the Type Name property is used as the name of an automatically generated C# class name, it must be a valid C# identifier and cannot be a reserved BizTalk keyword.

And in this case – when working with multiple root nodes in a single schema – it is not allowed the use of hyphens or other punctuations like “.”, “!” and so on, with the exception for the underscore (_).

We saw in the previous post that we could work around this “limitation” in schemas with a single root node by open the Schema with XML (Text) Editor and fix the “rootTypeName” for the value you want. In this case, it will not work.

Solution

As hyphens, or any other punctuation characters, are not allowed, the only solution you have is to change it from the “RootNode TypeName” property. For example:

  • For the node “My-NANE-SANDRO” the “RootNode TypeName” value can be “MyNAMESANDRO” or “My_NAME_SANDRO” instead of “My-NAME-SANDRO”
  • And for the node “Let-SEE-What-happens” the “RootNode TypeName” value can be “LetSEEWhathappens” or “Let_SEE_What_happens” instead of “My-NAME-SANDRO

By removing all hyphens, or any other punctuation characters, from this property in all schemas you will guarantee that you will not face this issue again at least in this project.

Conclusion

As a best practice you should use hyphens, or any other punctuation characters in the “RootNode TypeName”, nevertheless:

  • The use of hyphens or any other punctuation characters is allowed in schemas with a single root node;
  • The use of hyphens or any other punctuation characters is not allowed in schemas with multiple single root node;

And by the way, can my root node name still contain hyphens or any other punctuation characters?

Yes, it can. In all scenarios as long the root “RootNode TypeName” property doesn’t contain any of them as you will see in the picture below:

BizTalk Schema: Invalid type name error resolved

Author: Sandro Pereira

Sandro Pereira lives in Portugal and works as a consultant at DevScope. In the past years, he has been working on implementing Integration scenarios both on-premises and cloud for various clients, each with different scenarios from a technical point of view, size, and criticality, using Microsoft Azure, Microsoft BizTalk Server and different technologies like AS2, EDI, RosettaNet, SAP, TIBCO etc. He is a regular blogger, international speaker, and technical reviewer of several BizTalk books all focused on Integration. He is also the author of the book “BizTalk Mapping Patterns & Best Practices”. He has been awarded MVP since 2011 for his contributions to the integration community. View all posts by Sandro Pereira

Demystify Invalid type name error on BizTalk Schemas (Part I)

Demystify Invalid type name error on BizTalk Schemas (Part I)

A few days ago, while trying to compile a BizTalk Server solution I got the following error: Invalid type name. The root node type has to be a valid C# identifier. I end up solving this problem but while I was preparing this post the reason I realize that the cause and respective solution that I thought to be behind this error was, in fact, incomplete and not accurate.

Most of the documentation available state that:

  • The .Net framework doesn’t allow the “-” within TypeNames because the “-” is reserved.
  • The use of a hyphen (-) in RootNode TypeName is not allowed.

And that statement is incorrect or at least incomplete!

1) What happens if I create a root node with hyphens (-)?

If we create a root node with hyphens, let’s say “My-NAME-SANDRO”, by default the:

  • The “NodeName” property will be set as “My-NAME-SANDRO”;
  • And the “RootName TypeName” property will also be set as “My-NAME-SANDRO”;

And as you can see in the picture below, you will be able to create a schema with a one or more hyphens (-) on the root node name and type name, in fact, they should be the same if you only have one root node in the schema.

BizTalk Schemas: Invalid type name doesn't happen

And again, as you see in the picture you will be able to build and deploy it with success.

But, let’s play a little in order to demystify this Invalid type error that sometimes happens.

2) What happens if we try to change the “RootNode TypeName” property to other value like “MyNAMESANDRO” – without any hyphens (-)?

Nothing will happen, we will still be able to compile and successfully deploy our schema.

BizTalk Schemas: Invalid type name doesn't happen

In fact, this is the best approach.

3) Now, what happens if we try to change the “RootNode TypeName” property to other value like “My-NAMESANDRO” – with hyphens (-)?

Note, that we are changing to a “RootNode TypeName” property to a different value than the “Node Name” but this time including one or more hyphens (-).

If we try to do that we will receive the following error:

Invalid type name. The root node type name has to be a valid C# identifier. It cannot be same as the type name of any other root nodes in this schema

BizTalk Schemas: Invalid type name

Cause

Official Microsoft documentation state that the Type Name property of this schema file is not valid. Because the value of the Type Name property is used as the name of an automatically generated C# class name, it must be a valid C# identifier and cannot be a reserved BizTalk keyword.

In fact, it will not allow, any hyphens or other punctuations like “.”, “!” and so on with the exception of the underscore (_)… directly from the BizTalk Editor – we will get that sorted out (properly cleared) later.

Solution

As hyphen, or any other punctuation characters, are “not allowed”, you should “removed it” from the “RootNode TypeName” property. For example:

  • For the node “My-NANE-SANDRO” the “RootNode TypeName” value can be “MyNAMESANDRO” or “My_NAME-SANDRO” instead of “My-NAMESANDRO” or event “My-NAME_SANDRO”

By removing all hyphens, or any other punctuation characters, from this property in all schemas you will guarantee that you will not face this issue again at least in this project.

4) I change to “MyNAMESANDRO”, what happens if we try to roll back and change the “RootNode TypeName” property again to the original “My-NAME-SANDRO”?

Here’s where the story becomes funny, it will fail!

BizTalk Schemas: Invalid type name

Humm… what? How that’s possible if in point 1 we saw that if the root node name and type name is the same it should work, and it did work before?

Cause

Again, official Microsoft documentation state that the Type Name property of this schema file is not valid. Because the value of the Type Name property is used as the name of an automatically generated C# class name, it must be a valid C# identifier and cannot be a reserved BizTalk keyword.

In fact, once you change the name for something else without hyphens or any other punctuation characters, you cannot rollback to the origin (or default) RootName TypeName “My-NAME-SANDRO”.

Solution

The same solution here, as a hyphen, or any other punctuation characters, are “not allowed”, you should “removed it” from the “RootNode TypeName” property. For example:

  • For the node “My-NANE-SANDRO” the “RootNode TypeName” value can be “MyNAMESANDRO” instead of “My-NAMESANDRO” or event “My-NAME_SANDRO”

However, if you want to rollback to the default RootNode TypeName value, you need to delete the root node and recreate from the scratch, at least directly from the BizTalk Schema Editor.

What is actually the Cause

I think at some point in the past this was a limitation, or maybe a limitation in certain scenarios (we will check this on Part II later on in a different blog) but not really at the moment or in this case: a schema with a single root node.

So, if it worked in the first approach – point 1 – why doesn’t work in the other approaches – point 3 and 4?

Well, in this case, this is just a BizTalk Schema Editor limitation or bug, but let’s call it a limitation.

What is actually the Solution

To solve point 3 and 4 you just need to open the Schema with XML (Text) Editor:

05-BizTalk-Schema-Invalid-type-name-OK

And fix the “rootTypeName” for the value you want: “My-NAMESANDRO” or back to “My-NAME-SANDRO”

<?xml version="1.0" encoding="utf-16"?>
<xs:schema xmlns="http://BizTalk_Server_Project1.Schema1" xmlns:b="http://schemas.microsoft.com/BizTalk/2003" targetNamespace="http://BizTalk_Server_Project1.Schema1" xmlns:xs="http://www.w3.org/2001/XMLSchema">
  <xs:element name="My-NAME-SANDRO">
    <xs:annotation>
      <xs:appinfo>
        <b:recordInfo rootTypeName="My-NAMESANDRO" />
      </xs:appinfo>
    </xs:annotation>
    <xs:complexType>
      <xs:sequence>
        <xs:element name="First-Name" type="xs:string" />
        <xs:element name="Last_Name" type="xs:string" />
      </xs:sequence>
    </xs:complexType>
  </xs:element>
</xs:schema>

Save it, you now can open it again with BizTalk Schema Editor, compile it and deploy it with any problem.

Keep posted for Part II of this blog post.

Author: Sandro Pereira

Sandro Pereira lives in Portugal and works as a consultant at DevScope. In the past years, he has been working on implementing Integration scenarios both on-premises and cloud for various clients, each with different scenarios from a technical point of view, size, and criticality, using Microsoft Azure, Microsoft BizTalk Server and different technologies like AS2, EDI, RosettaNet, SAP, TIBCO etc. He is a regular blogger, international speaker, and technical reviewer of several BizTalk books all focused on Integration. He is also the author of the book “BizTalk Mapping Patterns & Best Practices”. He has been awarded MVP since 2011 for his contributions to the integration community. View all posts by Sandro Pereira

BizTalk Schema Problems: The type or namespace name ‘SerializableAttributeAttribute’ does not exist in the namespace

BizTalk Schema Problems: The type or namespace name ‘SerializableAttributeAttribute’ does not exist in the namespace

An error never comes alone … When an error appears, it always appears two or three, and I still have thousands to published, but this one but this one made me crazy for a few minutes: The type or namespace name ‘SerializableAttributeAttribute’ does not exist in the namespace!

Yes, you read it right, while I was trying to compile a RosettaNet schemas projects, in this particular case a PIP3B2 Advance Shipment Notification I got thousands of errors, 3054 to be exact saying:

Error 1 The type or namespace name ‘SerializableAttributeAttribute’ does not exist in the namespace

RosettaNet.Common.Schemas._3B2.System’ (are you missing an assembly reference?)

C:TFS…RosettaNet.Common.Schemas.3B2DomainLogisticsCodeListRN_FreightPaymentTerms_01_03.xsd.cs 9 13 RosettaNet.Common.Schemas.3B2 …

Error 3054 The type or namespace name ‘NonSerializedAttribute’ does not exist in the namespace ‘RosettaNet.Common.Schemas._3B2.System’ (are you missing an assembly reference?) C:TFS… RosettaNet.Common.Schemas.3B2DomainProcurementINT_Procurement_02_07_01_09.xsd.cs 5072 21 RosettaNet.Common.Schemas.3B2

… and several other schemas as you may see in the picture below.

namespace name 'SerializableAttributeAttribute' does not exist in the namespace

But do not be fooled into thinking this is a problem related exclusively to RosettaNet, it is not, and it can happen with any “normal” or any kind of schemas.

Cause

There are certain keywords, type names, and identifier names that you should use because they are internally used by BizTalk and it way enter in conflict and sometimes originate problems and errors, keywords like activate, atomic, body, task, compensate, method and several ones, you can see the full list here XLANG-s Reserved Words. But there are other keywords that depending on the artifact, may give you problems like:

  • BTS (associated with Microsoft.BizTalk.GlobalPropertySchemas assembly)
  • “-“ in RootNode Typename inside schemas

And “System”!

If you use the keyword “System” inside a schema namespace like:

  • RosettaNet.Common.Schemas._3B2.System
  • “MyNamspace.System.Schemas”

You will not be able to compile your schema project.

The problem, if you download from the GS1 RosettaNet Standards certain PIP’s they will have the following structure:

namespace name 'SerializableAttributeAttribute': RosettaNet PIP3B2 Sctructure

And as you see, there is a folder “System” that inside have several schemas and normally the schema namespace is composed by the project name or (assembly name) and the path to the schema, for example in this case:

  • RosettaNet.Common.Schemas._3B2.System.CodeList
  • Or RosettaNet.Common.Schemas._3B2.System

And this is causing all of these problems because in this case, “System” is a reserved keyword that shouldn’t be used.

Solution

The difficult part of this error was finding the cause of the problem. Once you know what is causing the problem the solution is quite simple. You just need to:

  • Change the “Namespace” property on all the schemas the word “System” to another name, for example, “_System” (to maintain the consistency but it can be other word/value)

In my case, I hade the change the “Namespace” property of the schemas in the “System” folder

namespace name 'SerializableAttributeAttribute': Change schema namespace

You can now rebuild your schema solution and this error should go away.

Author: Sandro Pereira

Sandro Pereira lives in Portugal and works as a consultant at DevScope. In the past years, he has been working on implementing Integration scenarios both on-premises and cloud for various clients, each with different scenarios from a technical point of view, size, and criticality, using Microsoft Azure, Microsoft BizTalk Server and different technologies like AS2, EDI, RosettaNet, SAP, TIBCO etc. He is a regular blogger, international speaker, and technical reviewer of several BizTalk books all focused on Integration. He is also the author of the book “BizTalk Mapping Patterns & Best Practices”. He has been awarded MVP since 2011 for his contributions to the integration community. View all posts by Sandro Pereira

Flat File Schema Properties Now Easily Accessible in SP1

In addition to all the other cool stuff available in BizTalk Server 2004 Service Pack 1 is the addition of the Additional Flat File Schema Properties to the schema properties window when working with Flat Files. 



Now, properties like Allow Early Termination, Generate Empty Nodes, Lookahead Depth, Parse Optimization, and Suppress Empty Nodes can be set inside Visual Studios.  This will eliminate the tedious and error prone manual editing of the schema using notepad.  Error prone?  Yep, I messed this one up once…

Error Fixed In Flat File Disassembler Sample

Today I was working on some content for Tech Ed when I found a major error in a sample I posted about 4 months ago. 



The error caused the CR-LF’s between records to be included in the positional character count during debatching and actually into the messages themselves.  This through off the file layout but did not give any errors.  In fact, the expected result of three files were received.  They just did not have the right data in them. 



I have seen similar problems in the past were the Flat File Disassembler does not behave in any way as I would expect.



Below is before and after screen shots of the schema.


Before: After:         



The error is easily fixed by added an additional node into the schema that is Delimited, Post Fixed with CR-LF as the Hexadecimal delimiter.  This fix was required in both the Header and SingleRecord schemas.



The updated sample is available for download.



Download: Flat File Disassembler Sample
Watch the video: Flat File Disassemblier Output Options Video

Property Promotion and Demotion in BizTalk

I think most BizTalk users have some idea about what Property Promotion is.  I would say Property Promotion is the process of taking message or system data and putting it into the message context.  The tricky part is when and how properties get promoted.



The items that are promoted using a property schema attached to your schema are promoted in the pipelines.  When and how the system properties are promoted is somewhat of a mystery.  I think some items are promoted in the adapters (like the specific file, HTTP, and FTP properties) while others seem to be promoted as the messages enters or leaves the Orchestration (like Sending Orchestration Type).  



Some properties are only available inside the Receive Pipeline and Orchestration (like Received Port Name and Received File Name).  In the sample below I manually copy them into the message inside the Orchestration.



It is possible to overwrite read only properties inside the pipeline (like MessageType).  This is dangerous but I am sure could have some benefits.  The MessageType property is read only inside the Orchestration but if it is promoted inside the Receive Pipeline the promoted value is used rather then the true message type.



It appears that system properties that are manually promoted in the Receive Pipeline are carried throughout the whole message flow and the system does not change them.  I can set Message ID to 12345 on the Receive Port and that value comes back out on the Send Port.  But, this message ID does not seems to actually be used internally. 



MessageType on the other hand is used by the system if promoted in the Receive Pipeline.  If I change this property, it shows up in HAT with the value I set for it.  I have found one exception to this.  It is the MessageType property when working with untyped messages.  That property is cleared when the message is sent out of the Orchestration.



Property Demotion.  This is something a little less known to BizTalk users.  This is the process of taking message context data and putting it into the message.  This is done in the Send Pipeline.  It is sometimes hard to determine what values are actually in the context and only values in the message context can be demoted. 



CRITICAL: If you use a pass through pipeline your properties are not demoted.  They are only demoted using the XML Assembler component.



Ok, so how do you go about Demoting values into your message?  First, you have to add the Property Schema to your schema that contains the values you want to demote.  If you want BTS System properties follow the steps below.



How to add the BizTalk System Properties Schema to your Schema:


1. Go to the Promote Properties Dialog Box


2. Go to Property Fields Tab


3. Go to the BizTalk Type Picker by clicking on the folder icon


4. Expand Microsoft.BizTalk.GlobalPropertySchema


5. Select BTS.bts_system_properties



Then, follow the same steps just like you are promoting the properties by selecting the elements you want to promote and select the corresponding element in the Property Schema.  It is that simple.



CRITICAL: If you have the same schema on the inbound and outbound you may inadvertently promote or demote values.



I have put together a sample working with both Typed messages and Untyped messages.  I have included several start messages that set various values.  You can check out the schema to see how I accessed the propertied for Promotion and Demotion.



DOWNLOAD: Promotion and Demotion Sample



Take Away: Property Promotion and Demotion is an important part of BizTalk allowing for message context data to be demoted into a message that is sent out of the system.

Property Schema and Promoted Properties In Custom Pipelines

Topics Covered:


– Custom promoted properties inside a pipeline


– Schema Property: “Property schema base”


– Direct binding to the message box


 


I have spent a lot of time in the past few weeks working with promoted properties through property schemas.  I was using the standard approach, to simply set the promoted properties inside the schema.  This, in turn, would allow the properties to be promoted inside the pipeline with no additional effort on my part.


 


This led me into working with custom pipelines that promoted additional properties that are not inside my message.  Once custom properties are promoted, I wanted to use these items for routing to an Orchestration. 


 


Example: I want everything processed by pipeline X and pipeline Y to promote a property named myCustomProp that says “I belong to group A”.  Then, I want all group A items to be processed by Orchestration 1.  I accomplished this by writing a custom pipeline component that promotes predefined text into myCustomProp.  Then, I used direct message box binding on the Receive Shape of the Orchestration to pick up message that have this property. 


 


CRITICAL: You will need to change this property inside the Orchestration to something other then “I belong to group A” before you send the message.  Otherwise, when you send it and the Orchestration will start again because it will match the subscription again.


 


The key point here is I want to set up a filter shape based on my new promoted property that I promoted inside my custom pipeline.  This property does not exist inside the schema of my received message.  I started getting the following error when I tried to build my Orchestration:


 


“message data property ‘MyPropertySchema.myCustomProp’ does not exist in messagetype ‘msgStart’


 


Ok, so what does this mean? 


BizTalk is helping you out my looking inside your message and telling you ahead of time that your property does not exist.  What a great feature, but in this case we do not want this enforced.


 


How do I fix it?


Simple solution… Although it took me hours to figure out. 


There is a property that can be set on each element node inside your property schema.  This property is inside the Reference sections named Property Schema Base. 


 


What is this used for?


It is used to specify the origin of the data that will be promoted into that Element in the Property Schema.  I did not realize how important this property was. 


 


The two values for this property are:


MessageDataPropertyBase (Default) – This means the data used to populate this field will come from a message


 


MessageContextPropertyBase – This means the data use to populate this field may or may not exist in a message.  i.e. it could be prompted inside a custom pipeline and set to values not inside the message.


 


Well, it turns out that setting the Property to the correct value is the key to building your Orchestration. Setting this value to MessageContextPropertyBase will allow the Orchestration build since this property will not be expected inside the message.


 


Take Away: When you are working with Promoted Properties that may or may not be included inside your message make sure you set the Property Schema Base property to MessageContextPropertyBase.

Root Node Type Name Vs Node Name

I just wanted to take a second to get everyone on the same page since these properties are VERY important in BizTalk. 

If you are a solo developer or you have never renamed a root node, then you may not understand the importance of these properties.First off, what are they?

Node Name: This is the name that is displayed inside Visual Studio for the root node in the schema and for each field element in a property schema.

Root Node Type Name:  Basically, this is what BizTalk will call your root node.  This does not have to be the same as the Node Name, thus the potential for confusion. 

The root node will default to the same name as your root node name when you first create the node or when you rename the root node by changing the Node Name property.  But, it is possible to change the Root Node Type Name, either by accident or on purpose, to something else that is non-meaningful to anyone.

Ok, but how will this really effect me? BizTalk sets a message context property called BTS.MessageType.  This is a concatenation of the document namespace and Root Node Name.  This message type property will show up in HAT and can also cause problems when working with non-unique root nodes with no namespace, but that is a whole other post.

What purpose does this serve? This will allow you to have two schemas with no namespace or the same namespace and the same root node name, but different root node type name.  The benefits of this may not be obvious, but it will allow you to set the message type property inside the pipeline.  This is required if you want to use the message for routing, mapping, or inside a strongly typed orchestration. 

If you do have two messages with no or the same namespace and the same root node type name you may get the follow error at runtime:

There was a failure executing the receive pipeline: "Microsoft.BizTalk.DefaultPipelines.XMLReceive" Source: "XML disassembler" Receive Location: "d:\bt\in\*.xml" Reason: The disassembler cannot retrieve the document specification by using this type: "Root123". Either the schema is not deployed correctly, or more than one schema is deployed for the same message type. 

The same holds true for schemas name and type name on the file properties of a schema.  The schema name has a Type Name property that is used inside the BizTalk Type Picker to reference that schema.  If this name gets changed on accident, it may become difficult for other developers to reference your schema.

CRITICAL: Unlike the Root Node, the file Type Name property will NOT change if the schema is renamed.

Take Away: Be mindful of the Type Name properties on the file and root node level and double check them to make sure they are set correctly.