Posts Tagged ‘Developer’

In the previous post I provide a fix to the PowerShell script to that is able to configure the Deployment Properties of a BizTalk project, keeping my word, at least half of it, because I also found the same problems in the PowerShell script to fix or configure the Signing Properties of a BizTalk Project, i.e., it only worked if the signing properties already existed in the file(s) (.btproj). This means that:

  • if we obtain a copy of the project from the source control that have already have these properties defined, it will work otherwise the script was unable to properly set these properties.
  • if we were working on a new project then definitely the script didn’t set up the signing properties.

Again, I promised that I would fix it and now I’m keeping the rest of my word. Along with the previous, this is probably one of scripts that I use the most and the reason why is…

So, why this script is important?

Again, and this is nothing new, before deploying a BizTalk project we must first strongly sigh the assemblies involved in the project to give them a unique identification for allowing them to be installed into the GAC.

GAC (Global Assembly Cache) is a machine code cache that stores assemblies that can be shared by multiple applications on the computer. This assemblies needs to be strongly signed so that they can have a unique identification in the GAC.

A strong-named assembly provides several security benefits:

  • A strong name guarantees the uniqueness of the assembly by assigning a digital signature and a unique key pair.
  • A strong name protects the lineage of the assembly by ensuring that no one else can generate a subsequent version of the assembly.
  • A strong name provides a strong integrity check to guarantee that the contents of the assembly have not changed since the last build.

In the process of deploying a BizTalk solution, Visual Studio first builds the assemblies. The deployment process requires that each assembly is strongly signed. You can strongly sign your assemblies by associating each project in the solution with a strong name assembly key file. That is an easy and rapid task (non-time consuming task). However, if a solution in Visual Studio contains multiple projects, you must separately configure properties for each project.

This seems a slight and easy task but now imagine that you have almost 200 projects inside a unique Visual Studio Solution! It will be an insane operation and the most likely to happen is you to fall asleep in front of the pc… once again.

With this PowerShell you will be able to parameterize all projects inside a Visual Studio Solution running a single line of code and avoid spending numerous hours doing this task manually.

PowerShell script overview
    $allPropertyGroup = $xml.Project.PropertyGroup
    foreach($node in $allPropertyGroup)
    {
        if($node.AssemblyOriginatorKeyFile -ne $null)
        {
            $addNewKeyNodeFlag = $false;
            $node.AssemblyOriginatorKeyFile= $keyName;
        }

        if($node.SignAssembly -ne $null)
        {
            $addNewSignNodeFlag = $false;
            $node.SignAssembly= $true;
        }
    }

    if($addNewKeyNodeFlag -eq $true)
    {
        $childItemGroup = $xml.CreateElement("PropertyGroup",$xdNS)
        $childNone = $xml.CreateElement("AssemblyOriginatorKeyFile",$xdNS)
        $childNone.AppendChild($xml.CreateTextNode($keyName));
        $childItemGroup.AppendChild($childNone)
        $xml.Project.InsertBefore($childItemGroup, $xml.Project.ItemGroup[0])
    }

    if($addNewSignNodeFlag -eq $true)
    {
        $childItemGroup = $xml.CreateElement("PropertyGroup",$xdNS)
        $childNone = $xml.CreateElement("SignAssembly",$xdNS)
        $childNone.AppendChild($xml.CreateTextNode($true));
        $childItemGroup.AppendChild($childNone)
        $xml.Project.InsertBefore($childItemGroup, $xml.Project.ItemGroup[0])
    }

    $allItemGroup = $xml.Project.ItemGroup.None;
    foreach($node in $allItemGroup)
    {
        if($node.Include -eq $keyName)
        {
            $addKeyToSolutionFlag = $false;
        }
    }

    if($addKeyToSolutionFlag -eq $true)
    {
        $childItemGroup = $xml.CreateElement("ItemGroup",$xdNS)
        $childNone = $xml.CreateElement("None",$xdNS)
        $childNone.SetAttribute("Include", $keyName)
        $childItemGroup.AppendChild($childNone)
        $xml.Project.InsertBefore($childItemGroup, $xml.Project.Import[0])
    }
THIS SQL SCRIPT IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND.

You can download the PowerShell Script used here from:

BizTalk Server: Fixing BizTalk Project Signing Properties with PowerShell (2 KB)
Microsoft | TechNet Gallery

It is nothing new that before you can deploy a solution from Visual Studio into a BizTalk application, you must first set project properties, especially the Server and the Configuration Database. Otherwise two things may happen:

  • Deployment will fail when you try do to deploy it through Microsoft Visual Studio or will you are redeploying a previously deployed BizTalk project.
  • The assemblies and all their artifacts will be deployed to and unwanted BizTalk Application (normally BizTalk Application 1)

Previous I wrote a post regarding how to fix the Deployment Properties of a Visual Studio BizTalk Project with PowerShell, you can know more about it here. However, during my talks about tips and tricks I realize that the previous script was a little limited, it only worked if the deployment properties already exist in the file. This means that, if we were working on a new project or we obtaining a copy of the project from the source control, the script didn’t correctly setup or fix the deployment settings.

I promised that I would fix it and now I’m keeping my word. And I have to say that, this is probably one of scripts that I use the most and the reason why is…

So, why this script is important?

Well, if a solution in Visual Studio contains multiple projects, you need to manually configure the deployment properties for each project.

And you must keep in mind that these setting are under the Project user option file(s) (“*.btproj.user”) that are typically not under source control. The reason is that the Visual Studio deployment feature main focus is for development scenarios where one user settings might differ from another. And it will be up to you, or your client, to decide if you want these files to be checked in and available to all of the developers on your team. (you can read it more about this here)

So, this seems a slight and easy task but now imagine that you have almost 200 projects inside a unique Visual Studio Solution! It will be an insane and consuming task to do and most likely to happen is you to fall asleep in front of the pc.

With this PowerShell you will be able to parameterize all projects inside a Visual Studio Solution running a single line of code and avoid spending numerous hours doing this task manually.

PowerShell script overview
    $allPropertyGroup = $xml.Project.PropertyGroup
    foreach($node in $allPropertyGroup)
    {
        if($node.Server -ne $null)
        {
            #If the Deployment Setting already exists, then we just need to update them
            $addNewNodeFlag = $false
            $node.Server= $ServerName;
            $node.ConfigurationDatabase= $DatabaseName;
            $node.ApplicationName= $ApplicationName;
            $node.Redeploy= $RedeployFlag;
            $node.Register= $RegisterFlag;
            $node.RestartHostInstances= $RestartHostInstancesFlag;
        }
    }

    if($addNewNodeFlag -eq $true)
    {
        #Add a PropertyGroup node if the Deployment Setting doesn't exist
        $newXmlPropertyGroup = $xml.CreateElement("PropertyGroup", "http://schemas.microsoft.com/developer/msbuild/2003")
        $newXmlPropertyGroup.SetAttribute(“Condition”,”'`$(Configuration)|`$(Platform)' == 'Debug|AnyCPU'”);

        $newXmlElement = $newXmlPropertyGroup.AppendChild($xml.CreateElement("Server", "http://schemas.microsoft.com/developer/msbuild/2003"));
        $newXmlTextNode = $newXmlElement.AppendChild($xml.CreateTextNode($ServerName));
 
        $newXmlElement = $newXmlPropertyGroup.AppendChild($xml.CreateElement("ConfigurationDatabase", "http://schemas.microsoft.com/developer/msbuild/2003"));
        $newXmlTextNode = $newXmlElement.AppendChild($xml.CreateTextNode($DatabaseName));

        $newXmlElement = $newXmlPropertyGroup.AppendChild($xml.CreateElement("ApplicationName", "http://schemas.microsoft.com/developer/msbuild/2003"));
        $newXmlTextNode = $newXmlElement.AppendChild($xml.CreateTextNode($ApplicationName));

        $newXmlElement = $newXmlPropertyGroup.AppendChild($xml.CreateElement("Redeploy", "http://schemas.microsoft.com/developer/msbuild/2003"));
        $newXmlTextNode = $newXmlElement.AppendChild($xml.CreateTextNode($RedeployFlag));

        $newXmlElement = $newXmlPropertyGroup.AppendChild($xml.CreateElement("Register", "http://schemas.microsoft.com/developer/msbuild/2003"));
        $newXmlTextNode = $newXmlElement.AppendChild($xml.CreateTextNode($RegisterFlag));

        $newXmlElement = $newXmlPropertyGroup.AppendChild($xml.CreateElement("RestartHostInstances", "http://schemas.microsoft.com/developer/msbuild/2003"));
        $newXmlTextNode = $newXmlElement.AppendChild($xml.CreateTextNode($RestartHostInstancesFlag));

        $xml.Project.InsertAfter($newXmlPropertyGroup, $xml.Project.PropertyGroup[1])
    }

THIS SQL SCRIPT IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND.

You can download the PowerShell Script used here from:

BizTalk Server: Fixing BizTalk Project Deployment Properties with PowerShell (1 KB)
Microsoft | TechNet Gallery

In the previous post it was provide a PowerShell script to fix or configure the Deployment Properties of a BizTalk project. However, and this is also nothing new, before deploying a BizTalk project we must first strongly sigh the assemblies involved in the project to give them an unique identification for allowing them to be installed into the GAC.

GAC (Global Assembly Cache) is a machine code cache that stores assemblies that can be shared by multiple applications on the computer. This assemblies needs to be strongly signed so that they can have a unique identification in the GAC.

A strong-named assembly provides several security benefits:

  • A strong name guarantees the uniqueness of the assembly by assigning a digital signature and a unique key pair.
  • A strong name protects the lineage of the assembly by ensuring that no one else can generate a subsequent version of the assembly.
  • A strong name provides a strong integrity check to guarantee that the contents of the assembly have not changed since the last build.

In the process of deploying a BizTalk solution, Visual Studio first builds the assemblies. The deployment process requires that each assembly is strongly signed. You can strongly sign your assemblies by associating the project with a strong name assembly key file. If you haven’t already done so, before deploying a solution from Visual Studio, use the following procedure to generate a strong name assembly key file and assign it to each project in the solution.

To configure a strong name assembly key file

  • In Visual Studio Solution Explorer, right-click the project and then click Properties.
  • Click the Signing tab and choose “Browse…” or “New…” in the Choose a strong name key file drop down box.
  • Create a new key or browse to the key file and click it. Click Open, and then close the project properties.
  • Repeat steps 3 through 6 for each project in the solution that you want to deploy using this strong name assembly key file.

Signing-Properties-BizTalk-Project-Visual-Studio

Once again, if a solution in Visual Studio contains multiple projects, you must separately configure properties for each project.

This seems a slight and easy task but now imagine that you have almost 200 projects inside a unique Visual Studio Solution! It will be an insane operation and the most likely to happen is you to fall asleep in front of the pc… once again.

With this PowerShell you will be able to parameterize all projects inside a Visual Studio Solution running a single line of code and avoid spending numerous hours doing this task manually.

    foreach($node in $allPropertyGroup) 
    { 
        if($node.AssemblyOriginatorKeyFile -ne $null) 
        { 
            $node.AssemblyOriginatorKeyFile= "<keyname>.snk"; 
        } 
    } 
 
    if($xml.Project.ItemGroup.None -eq $null) 
    { 
        $childItemGroup = $xml.CreateElement("ItemGroup",$xdNS) 
        $childNone = $xml.CreateElement("None",$xdNS) 
        $childNone.SetAttribute("Include", "<keyname>.snk") 
        $childItemGroup.AppendChild($childNone) 
        $xml.Project.InsertBefore($childItemGroup, $xml.Project.Import[0]) 
    }

You can download the PowerShell Script used here from:

BizTalk Server: Fixing BizTalk Project Signing Properties with PowerShell (2 KB)
Microsoft | TechNet Gallery

It is nothing new that before you can deploy a solution from Visual Studio into a BizTalk application, you must first set project properties, especially the Server and the Configuration Database. Otherwise two things may happen:

  • Deployment will fail when you try do to deploy it through Microsoft Visual Studio or will you are redeploying a previously deployed BizTalk project.
  • The assemblies and all their artifacts will be deployed to and unwanted BizTalk Application (normally BizTalk Application 1)

If a solution in Visual Studio contains multiple projects, you must separately configure properties for each project.

To configure project properties you normally need to:

  • In Visual Studio Solution Explorer right-click a project for which you want to configure properties, and then click Properties.
  • Click the Deployment tab in Project Designer.
  • Configure the following project properties
    • Application Name: Name of the BizTalk application to which to deploy the assemblies in this project. If the application already exists, the assemblies will be added to it when you deploy the project. If the application does not exist, the application will be created. If this field is blank, the assemblies will be deployed to the default BizTalk application in the current group. Names that include spaces must be enclosed by double quotation marks (“).
    • Configuration Database: Name of the BizTalk Management database for the group, BizTalkMgmtDb by default.
    • Server: Name of the SQL Server instance that hosts the BizTalk Management database on the local computer. In a single-computer installation, this is usually the name of the local computer.
    • Redeploy: Setting this to True (the default) enables you to redeploy the BizTalk assemblies without changing the version number.
    • Install to Global Assembly Cache: Setting this to True (the default) installs the assemblies to the Global Assembly Cache (GAC) on the local computer when you install the application. Set this to False only if you plan to use other tools for this installation, such as gacutil.
    • Restart Host Instances: Setting this to True automatically restarts all host instances running on the local computer when the assembly is redeployed. If set to False (the default), you must manually restart the host instances when you redeploy an assembly.
    • Enable Unit Testing: Specifies whether to enable unit testing for the project.
  • And then click OK.
  • Repeat steps 1, 2, and 3 for each project in the solution.

Deployment-Properties-BizTalk-Project-Visual-Studio

This seems a slight and easy task but now imagine that you have almost 200 projects inside a unique Visual Studio Solution! It will be an insane operation and the most likely to happen is you to fall asleep in front of the pc.

With this PowerShell you will be able to parameterize all projects inside a Visual Studio Solution running a single line of code and avoid spending numerous hours doing this task manually.

    $allPropertyGroup = $xml.Project.PropertyGroup 
    foreach($node in $allPropertyGroup) 
    { 
        if($node.Server -ne $null) 
        { 
            $node.Server= "<BizTalkServer>"; 
            $node.ConfigurationDatabase= "BizTalkMgmtDb"; 
            $node.ApplicationName= "<BTSApplicationName>"; 
            $node.Redeploy= "False"; 
            $node.Register= "True"; 
            $node.RestartHostInstances= "False"; 
        } 
    }

You can download the PowerShell Script used here from:

BizTalk Server: Fixing BizTalk Project Deployment Properties with PowerShell (1 KB)
Microsoft | TechNet Gallery

Last Monday I presented my second session in the Integration Monday series (see my last post) and, as usually, I normally publish a post on my blog before the event – a way to help the organizers to advertise the event – or sometimes after the event sharing the resources… but I just now realized that I never created a post in my blog about my first session in the Integration Monday series: BizTalk Server Tips & Tricks for Developers and Admins (Deep Dive)

A session similar to the one I did in BizTalk Summit 2015 London event (also available online here) but a more open session addressing more tips and going into more detail – because I had more time, almost 82 minutes comparing to the 30 minutes I had in London Smile – and according to the Integration Monday organizers it has been a quite popular (or viewed) session.

Integration-Monday-organizers-tips-amd-tricks-feadback

So it is time to solve this "my big fault" and share with you the resources of this session – a session with a simple topic that I really love – I think that this (the topic) is the session that gave me more pleasure in making.

Sandro-Pereira-Integration-Monday-BizTalk-Server-Tips-Tricks-Developers-Admins-Deep-Dive

Session: BizTalk Server Tips & Tricks for Developers and Admins (Deep Dive)

Abstract: It’s critical to use good tools and techniques to produce working solutions as quickly as possible and at the same time, given the increase the requirements and number of applications organizations develop today. But at the same time, it’s also critical to maintain the health of the entire platform. In this session I’ll address and share some useful BizTalk Server Tips and Tricks (and Workarounds) both for developers and administrators that we can use in our daily work. And by doing so I’m hoping to simplify a little and/or automate some of the repeating tasks that we normally do and by sharing some unusual things or techniques that we can use I’m hoping to help you simplify your BizTalk solutions. Covering some topics like RosettaNet, SAP, database maintenance, debatching, out-of-the-box pipelines vs custom pipelines and many more

I hope you enjoy and find it an interesting session. Also I advise you to visit and view the sessions history that have taken place every Monday in the Integration User Group – Integration Monday series.

Probably this was one of the most talked and funny tips and I completely forgot to publish in my blog despite the resources despite the resources are already available for download and referenced in the session slides that you can found here.

If you are familiarly with the BizTalk Innovation Day or BizTalk Summit’s, you will all remember that at some point my dear friend Tord Glad Nordahl complaining in his session about BizTalk Developers writing unnecessary information in the Application Event Log and for they do not use the Event Viewer. You can also check his post and his point of view about this topic: BizTalk + Event log = angry admins

My goal here is not to criticize those who use the event viewer or if there is better way to accomplish this task (monitor/logging BizTalk applications errors)… but I partially have to agree with Tord and say that… you shouldn’t write custom application errors, warnings or information in the Application Event Log.

Many times BizTalk developers like to write information’s that will help them tracking and debugging there orchestrations like:

  • Message received
  • Message successfully Transformed
  • Message sent to external system

custom-source-logs-logged-application-event-log

And for that they normally use the following code:

System.Diagnostics.EventLog.WriteEntry("AnnoyingTord",
               "Just an update Tord! Message successfully Transformed");

The problem using this code is that by default these information is being logged in the Application Event Log. You need to realize that Application Event Log holds almost all the important information related to different aspects in BizTalk – SQL, IIS, BizTalk infrastructure and runtime problems – it is one of the main places that admins used to monitor “applications” installed in your server/machine. And these is the information that is extremely important for BizTalk Administrator in order to monitor the wellbeing of the platform and to diagnose problems and you don’t want to infest this event log with irrelevant and unnecessary information at the point to be almost impossible to find real problems – instead you, or in this case the admins, should keep it clean.

So I told – “I partially have to agree…” – because I think that this are unnecessary information that are being logged in the Application Event Log that doesn’t provide any additional information to BizTalk Administrators but…

But I told – “I partially have to agree…” – because, instead, you can use a custom event log for logging that unnecessary information that doesn’t provide any additional information to BizTalk Administrators and in this case I really don’t care if you are using the Event Viewer to log BizTalk application errors or tracking or debugging information (despite I don’t agree this last part).

So you can use the Event viewer as long as you do not use the Application Event Log to write custom errors.

Building the Sample

In this sample you will find a simple orchestration that will receive any XML message and will log some traditional tracking information that developers normally do in their orchestrations… I call this trying to annoying Tord Glad Nordahl (my friend and one of the best BizTalk Administrator that I know):

Trying-to-Annoying-Tord

The source code can be found and download on MSDN Code Gallery:
BizTalk Server: Moving Event Source To Different Event Log (Administration) (152.2 KB)
MSDN Code Gallery

 

What the Admin does normally?

When facing this type of development, BizTalk Administrators normally ask the developer’s to change their code, to not write in the application log or to disable this type of logging/tracking. Code that already is deployed in all the environments.

However change is hard – Getting others to change can be impossible or a big challenge – Developers will try to find a thousand excuses for explaining why such information is important!

What the Admin should do?

My advice:

• Let the developer by happy by writing in the Event Viewer

But take back the control of your environment by easily creating or using PowerShell

With this script you can easily move an Event Source to a different or to a Custom Windows Event Log:

foreach ($LogSource in $LogSources) {
    Remove-EventLog -Source $LogSource
} 

$logFileExists = Get-EventLog -list | Where-Object {$_.logdisplayname -eq $LogName}
if (! $logFileExists) {
    $LogSources | %{
        New-EventLog -LogName $LogName -Source $_
    } 

    # Compose Key:
    $LogPath = 'HKLM:\SYSTEM\CurrentControlSet\services\eventlog\'+$LogName;
    if(Test-Path $LogPath)
    {
        $acl = Get-Acl $LogPath
        $GpOrUsers | %{
            $ace = New-Object System.Security.AccessControl.RegistryAccessRule $_,'WriteKey, ReadKey','allow'
            $acl.AddAccessRule($ace)
            #Set-Acl $LogPath $acl
        }
    }else{Write-Error "Cannot acesss log $LogName"}
}
else {
    $LogSources | %{
        New-EventLog -LogName $LogName -Source $_
    }
}

moving-source-logs-to-another-event-log

This way, you as an admin can take back the control of your environment and fix the blunders (or foolishness) of the developers – if you are a BizTalk developer, don’t be offended please, I’m also a BizTalk Developer.

The script can be found and download on Microsoft TechNet Gallery:
BizTalk DevOps: Moving an Event Source To a Different/Custom Windows Event Log (4.2 KB)
Microsoft TechNet Gallery

 

Again If you are a developer and you for some reason want to write “tracking” or error information in the Event Viewer, then you should start to optimize your code to write by default in a custom Event log. You can use for example a similar code:

string logName = “MyCustomEventLog”;
string logName = “MyProjectLogSource”;

if (!System.Diagnostics.EventLog.SourceExists(logName))
{
   System.Diagnostics.EventLog.CreateEventSource(projectName, logName);
}
System.Diagnostics.EventLog.WriteEntry(projectName, genericString.ToString(), logType);

As most of you already know, last month I presented a session at BizTalk Summit 2015 London event about “BizTalk Server tips and tricks for developers and admins” (You can check the video recording of my session here)

It was a lightweight session (30 minutes) about useful tips that we can use in our daily work, because it was a small session I didn’t had enough time to cover everything, so I end up creating a “Director’s cut…” session with additional tips that you can check in the presentation slides here.

Today, and because I already received some emails regarding this topic, I will address the “Database Lookup functoid

We can use the Database Lookup functoid to extract information from a database and store it as a Microsoft® ActiveX® Data Objects (ADO) recordset. This functoid requires four input parameters in the following order:

  • Parameter 1: A value for which to search in the specified database, table, and column.
  • Parameter 2: The full connection string for the database with a provider, machine name, database and authentication (an ActiveX Data Objects .NET (ADO.NET) connection string)
  • Parameter 3: The name of the table in the database in which to search.
  • Parameter 4: The name of the column in the table in which to search.

The functoid is actually quite simple to use, however, the main problem that developers face when they use it refers to the second parameter: the connection string. And why?

First: What is the correct value for the connection string?

I always find hard to remember the correct value for the connection string to be used inside this functoid.

Database-Lookup-Functoid-sample-configuration

The Easiest way to make sure we are using the correct connection string value and for not having to remember this by head is to create a simple Universal Data Link (.udl) File… set OLE DB provider connection parameters and test the connection to check if everything is correct.

To accomplish this we need to:

  • · Navigate to a folder in your system, can be in the desktop or preferably in a folder under your BizTalk visual studio solution, let’s call it “Resources”.
  • Create a text file and name it “ODBCConnectionTest.udl”
    • The name of the file is not important, the important part is the extension, it must be “.udl”
  • Double click the file you just created.

create-Universal-Data-Link-udl-File

  • On the Provider Tab, select the appropriate OLE DB provider for the type of data you want to access and then Next
    • In my case it is “Microsoft OLE DB Provider for SQL Server”

Universal-Data-Link-udl-Properties-Provider-tab

  • In the Connection tab, specify:
    • Where your data is located, typically the server and database name.
    • How to connect to it using an OLE DB provider: Use Windows NT integrated security or Use a specific user name and password
    • In this particular case, you need to provide the SQL Server, the database name we want to connect.

Universal-Data-Link-udl-Properties-Connection-tab

  • Then you can and should click on “Test Connection…” button to attempt a connection to the specified data source. If no connection is made, review the settings. Otherwise click “Ok”

Universal-Data-Link-udl-Properties-Test-Connnection

After data Open the “ODBCConnectionTest.udl” file in notepad and you will find the connection string value that you can copy and use it in the second parameter of the Database Lookup Functoid.

Open-Universal-Data-Link-udl-File-notepad

This will lead us to the second problem that you can face using this functoid: using the connection string statically inside the Database Lookup Functoid

Hard-coding the SQL connection strings might lead to maintenance overhead and serviceability issues.

Important considerations:

  • You shouldn’t Hard-coding this value directly in the functoid otherwise it will be a nightmare when you deploy this to a different environment.
  • You can and you should store this parameter in a different storage location (SSO, Registry or others) and get this value using a scripting Functoid or custom functoid which can then be linked to the Database Lookup Functoid, like the:
    • BTSNTSvc Config Get Functoid: This functoid allows you to get configuration parameters from BTSNTsvc.exe.config. If there is no section specified, the functoid reads from the AppSettings.
    • Windows Registry Config Get Functoid: This functoid allows you to get configuration parameters from Windows Registry.
    • SSO Config Get Functoid: This functoid allows you to get configuration parameters from SSO Database.
    • Rule Engine Config Get Functoid: This functoid allows you to obtain a definition value from a Vocabulary in the Business Rules Engine.

In my personal opinion I advice you to use SSO or BRE to store this configuration parameters. All of these custom functoids are available in the BizTalk Mapper Extensions UtilityPack.

TIP-10-Database-Lookup-functoid

You can found and download the Source Code on MSDN Code Gallery:

BizTalk Mapper: How to use Database Lookup Functoid
Microsoft | MSDN Code Gallery

Exciting news for the BizTalk Community… specially the 200 persons that attended the BizTalk Summit 2014 London that already know the potential of BizTalk NoS addin!

Nino Crudele just public announce in is blog: BizTalk NoS Add-in Beta version has been officially released through Visual Studio Gallery that the BizTalk NoS Addin is now available for you to download it in install it on Visual Studio gallery at: BizTalk NoS Addin!!!!!

What is BTSG NoS Addin purpose?

The purpose of BTSG NoS addin is to help all BizTalk Developer, why not, all BizTalk Administrator too in a lot of different situations, by improving the developer experience and why not reduce the development time in new or existent BizTalk projects.

It will provide several functionalities like quick search inside artifact, fast register/unregister in GAC, find critical, internal or external dependencies… and many fore functionalities like JackHammering, which will compare your VS artifact with the artifact deployed in BizTalk environment, you can also extract the artifact (Orchestration, map, schema and so on) from BizTalk environment and put it in the VS solution or even test your pipeline in VS simply… several features that are usefully in our day by day work and a time saver in a lot of situations.

How can I install BTSG NoS Addin

You can install BTSG NoS Addin directly from Visual Studio “Extensions and Updates” option. For that you must:

  • Open Visual Studio as Administrator, go to the “Tools” menu and select the “Extensions and Updates” option.
  • In the “Extensions and Updates”, in the right panel select “Online” tab and search for “BizTalk” or for “BizTalk NoS Addin”.
  • And Download the BizTalk Nos Addin”.

The rest of the installation process is described in one of my previous post: How to install BTSG NoS Addin for Visual Studio 2012

You can find all the documentation about this addin in:

Or in my posts:

Special Note

It has been a challenge, an extreme playfulness and a privilege to work with my dear friend Nino Crudele! I feel extremely honored that Nino have chosen me to help in this final phase of his work and for that THANKS Nino!

_DSC2735

Now is time to take a small vacations of BizTalk NoS addin and finish my ongoing work: BizTalk Mapper Pattern eBook… witch of course Nino will be one of the reviewers J

In my last posts I’m being describing some of the features of BTSG NoS Addin. This is the final post about the overview of all features available with this Visual Studio addin and how can you use them.

Test Pipeline

There are many ways to test BizTalk pipelines: by using Biztalk Pipeline Framework to create unit testing, using the Pipeline.exe tool or by create and use them by implementing "for real" in BizTalk messaging scenarios. But there isn’t for real an easy build support feature in Visual Studio to test our custom pipelines.

Once again BizTalk NoS addin will provide that for you. This operation will test our custom pipeline pipelines directly from Visual STudio by simple right click and “Test Pipeline”:

BTSG-NoS-Addin-Test-Pipeline

  • Visual Studio will prompt a window for to select and instance of the message that you want to try against the pipeline.

BTSG-NoS-Addin-Test-Pipeline-open-file

  • and will show the result for the pipeline directly in VS IE

BTSG-NoS-Addin-Test-Pipeline-result

Test Pipeline Component

As the previous one testing or debugging a custom pipeline component can be a challenger and most of the times you will need to create and testing them by implementing and configuring a BizTalk messaging scenarios and then attach the BizTalk process in Visual Studio to debug the components.

You now will be able to debug your pipeline component attaching an external process from VS without care about BizTalk environment by:

  • Right click on the pipeline that contains the custom pipeline component that you want to try and select the option “Test Pipeline Component”:

BTSG-NoS-Addin-Test-Pipeline-Component

  • A window will be show that will describe all the steeps necessary for you to configure you testing scenario and debug the custom pipeline component

BTSG-NoS-Addin-Test-Pipeline-Component-2

  • The first thing you need to do is select an instance of a message that you want to try against the custom pipeline component, by clicking in the add wheel in the left:

BTSG-NoS-Addin-Test-Pipeline-Component-3

    • A window will prompt for to select and instance of the message

BTSG-NoS-Addin-Test-Pipeline-Component-open-file

  • The second step is to set a breakpoint in you custom pipeline component and attach the BTSG TestPipeline process with the Visual Studio Debugger by:
    • On the Visual Studio “Debug” menu, select “Attach to Process”

BTSG-NoS-Addin-Test-Pipeline-Component-attach-process

    • Select the BTSG.TestPipeline.exe process (the title will also contains the name of our pipeline) and click “Attach”

BTSG-NoS-Addin-Test-Pipeline-Component-attach-process-select

  • For the third and final step, you will need to go to the BTSG window to configure you testing scenario and debug the custom pipeline component, to submit the select message instance to debug it against the custom pipeline component, by clicking in the submit wheel in the right side:

BTSG-NoS-Addin-Test-Pipeline-Component-4

And you be able to start debug your custom pipeline component code.

Heuristics

Heuristics are basically the same of the above dependencies features (internal and external) but more useful during refactoring or before to do an update in an artifact. For example you need to modify an artifact and you want to know what will be the artifact update impact in the entire solution.

Other extreme situation could be, I want to know where this property schema or schema could be used, and this is not so simple to know because a property schema or schema could be used in lot of different way using his root nodes.

Heuristic Internal Propagation

This feature is basically the same as the “Internal Dependencies” but with the difference that we will also go ahead and will also the sub-levels of dependencies, i.e., the sub-artifacts.

BTSG-NoS-Addin-Heuristic-Internal-Propagation

You can access this features by:

  • Right click in your resource (file) name and select the “Heuristic Internal Propagation” option

BTSG-NoS-Addin-Heuristic-Internal-Propagation-option

Heuristic External Propagation

This feature is basically the same as the “External Dependencies” but with the difference that we will also go ahead and will also the sub-levels of dependencies, i.e., the sub-artifacts.

BTSG-NoS-Addin-Heuristic-External-Propagation

You can access this features by:

  • Right click in your resource (file) name and select the “Heuristic External Propagation” option

BTSG-NoS-Addin-Heuristic-External-Propagation-option

Heuristic Circular Propagation

This feature is basically the combination of both above heuristic operation (internal and external propagation) in a single operation.

BTSG-NoS-Addin-Heuristic-Circular-Propagation

You can access this features by:

  • Right click in your resource (file) name and select the “Heuristic Circular Propagation” option

BTSG-NoS-Addin-Heuristic-Circular-Propagation-option

Heuristic Anchoring Dependencies

Looking in all files in the solution for all artifact that could be associated with the artifact selected.

You can access this features by:

  • Right click in your resource (file) name and select the “Heuristic Anchoring Dependencies” option

BTSG-NoS-Addin-Heuristic-Anchoring-Dependencies-option

Heuristic Similarity Dependencies

Looking in all files in the solution for all artifact that could be associated (same solution domain, for example are using the same namespace) in any possible option, with the artifact selected.

You can access this features by:

  • Right click in your resource (file) name and select the “Heuristic Similarity Dependencies” option

BTSG-NoS-Addin-Heuristic-Similarity-Dependencies-option

Heuristic Contagion Dependencies

Looking in all files in the solution for all artifact that could be associated with the artifact selected, in all of possible combinations, type name, fields used, root name and more…

You can access this features by:

  • Right click in your resource (file) name and select the “Heuristic Contagion Dependencies” option

BTSG-NoS-Addin-Heuristic-Contagion-Dependencies-option

Finally all the features are documented… And we only need to wait the release announcement!!!!

In my last posts I’m being describing some of the features of BTSG NoS Addin. In this post we will continue to have an overview of all features available with this Visual Studio addin and how can you use them.

Locate it

How many times you open your old or new project will several files opened in the Visual Studio MDI window and you want a simple way to locate where this file is in your projects structure? For example: you are working in a transformation but know you need to locate the map file to specify a “TestMap Input Instance”… if don’t know exactly where it is, you need to check the full path of the map and then manually navigate in the solution explorer to the file that you want.

BTSG-NoS-Addin-Where-is-my-file

Finally now you will have an easy way to accomplish this! Which will save us much time in the developing process, for me this one of the basic stuff that is a timesaver.

Note: Even if you don’t have the “Solution Explorer” Window opened, this feature will find the file that you are locking for and will automatically open (or give the proper focus) the “Solution Explorer” window!

You can access these features by:

  • On the Visual Studio MDI window, right click in tab with the name of the file and select “Locate it!” option

BTSG-NoS-Addin-Locate-it

The result is, as you can see the picture below, the project will be expanded and the desired file will be selected:

BTSG-NoS-Addin-Locate-it-result

Again this is very useful for a BizTalk Developer because he needs to locate the file to test or generate schema instances or test, validate or debug maps.

Dependencies

This addin will provide several option to deal with dependencies between BizTalk artifacts. Choosing what to use will depend on the situation and what you want to archive.

External Dependencies

Sometimes we want to know who use this artifact. This is really useful in order to get a clear sense of where the changes that we need to do can have impacts. For example, if I need to change a schema, will this changes will have impact in my maps or in my orchestration? So I really need to know, before modifying my resource, which artifacts are using it.

You can access this features by:

  • Right click in your resource (file) name and select the “External Dependencies” option

BTSG-NoS-Addin-External-dependencies

The result is, as you can see the picture below, the project will be expanded and all the resources that are consuming the artifact will be selected:

BTSG-NoS-Addin-External-dependencies-result

Note: You will also have available the option to automatically open all the files (this is a behavior/functionality that you will find in many features).

BTSG-NoS-Addin-open-artifact-to-option

Internal Dependencies

Well if you like the previous one, this will be the opposite and also useful in several situations. In this case we want to know what this artifact is using (or which artifacts are consuming). For example: I need to modify the schema, or the schemas, used by a map… and you need to remember in huge solution this simple task to find schemas in your solution can be a challenger and a boring repeated task by BizTalk developers!

Don´t get me wrong, we have all the information on the map file by simply place the cursor over the schema:

BTSG-NoS-Addin-Where-is-my-file-schema

But again, out-of-the-box I don’t have any easy way to locate and open the schemas, I need to manually navigate in the solution explorer to the file that we want.

You can accomplish this by access this feature by:

  • Right click in your resource (file) name and select the “Internal Dependencies” option

BTSG-NoS-Addin-Internal-dependencies

The result is, as you can see the picture below, the project will be expanded and all the resources that being consumed by the artifact will be selected:

BTSG-NoS-Addin-Internal-dependencies-result

These are simple things/operations but they are timesaver for a BizTalk Developer. For example, about orchestration, I can ask internal dependencies and select the option “Open it”, because I want with one click to have available and ready to work all the artifact (schemas, maps and so on) to make all the necessary changes.

Critical dependencies

This feature van be found in the project context and will find all critical dependencies to solve the classical problem that you may have when deploying a project or solution, for example, an pipeline (or other artifact like map and so on) that exist in this project is being used by an external application, normally Visual Studio will generate an error about a foreign key database strict without to specify who the application is or what port that is using it.

BTSG-NoS-Addin-Visual-Studio-error-critical-dependencies

You can accomplish this by access this feature by:

  • Right click in the name of your project and select the “Critical Dependencies” option

BTSG-NoS-Addin-Critical-Dependencies

The result is, as you can see the picture below, the project will be expanded and all the resources that being consumed by the artifact will be selected:

BTSG-NoS-Addin-Critical-Dependencies-result

In this manner you can fix it and decide you deploy strategies

Heuristic Dependencies

We will talk about this features (there are 6 Heuristic Dependencies!) in another post.

Refactory

Similar with Reflector feature, the Refactory will create a more simple report with a circular reference (internal and external) with other artifacts that can be very useful to understand the refactory strategy to use.

You can accomplish this by access this feature by:

  • Right click on your artifact (Orchestration, map, schema…) and select the “Refactory” option

BTSG-NoS-Addin-Refactory

This feature will provide some statistics and information’s about

  • Who is using this artifact
  • And what artifacts this resource is consuming.
  • And some general information like complexity, persistent point and error handling (in orchestrations) and so on.

BTSG-NoS-Addin-Refactory-result