Google and Microsoft agree on something.
Saturday, August 31, 2013
Friday, August 30, 2013
PowerShell for BizTalk Administration: Is this thing on? Part 3
In Part 2 I outlined getting the status of BizTalk artifacts (Recieve Locations, Send Ports, and Orchestrations) using PowerShell. All 3 of those use the same pattern. Validating the status of the Host Instances, however, can be done without using the Microsoft.BizTalk.ExplorerOM.
Looking at the Host Instances (not Hosts) at a high level, they are nothing more than a Windows Service on a server. So two ways to get information on a service via PowerShell is use use either the Win32_Process or Win32_Service objects using the PowerShell Get-WMIObject command. However, there is a unique WMI object specifically for BizTalk: MSBTS_HostInstance. I chose the last one for my script. This does assume you have this class installed on the server you are making the call from.
Instantiating the object is a one-liner (no need to establish the SQL Server, as in the previous post). At that point you can loop through each host instance and get the state of the Host Instances.
Looking at the Host Instances (not Hosts) at a high level, they are nothing more than a Windows Service on a server. So two ways to get information on a service via PowerShell is use use either the Win32_Process or Win32_Service objects using the PowerShell Get-WMIObject command. However, there is a unique WMI object specifically for BizTalk: MSBTS_HostInstance. I chose the last one for my script. This does assume you have this class installed on the server you are making the call from.
Instantiating the object is a one-liner (no need to establish the SQL Server, as in the previous post). At that point you can loop through each host instance and get the state of the Host Instances.
Wednesday, August 14, 2013
PowerShell for BizTalk Administration: Is this thing on? Part 2
In Part 1, the story is set up that we may need to get some information on BizTalk in a quick, detailed way. We could certainly use the BizTalk Administration console, but I'd have to remote in to the server. Our security model makes that a little difficult.
So the first thing I'd like to check are the Receive Locations and the Send Ports. I want to create this in a script so I can run this at-will. There are a few ways to do this: NotePad being the most basic, or we could download the PowerShell ISE. But my favorite is SAPIEN PowerShell Studio. I'm still trying to figure out why Microsoft hasn't tightly integrated this kind of functionality to Visual Studio.
So back to the scenario. The object to use in both cases is the Microsoft.BizTalk.ExplorerOM.BtsCatalogExplorer:
You may notice the hard way that this object is a 32-bit only object. So, if you are running in a 64-bit mode of PowerShell, your script won't run. You will need to force 32-bit mode. This can be done with the following:
The above two snippets are the basis of setting up both Receive Locations and Send Ports. I'll first focus on the Send Ports. The first thing is to instantiate an object using the BizTalk Explorer Object Model. Once that's done, we'll need to connect to the proper BizTalk database. After that's done, it's a simple loop to go through each Send Port:
Receive Locations are nested one level deeper than Send Ports, otherwise they are essentially the same process.
And (surprise, surprise) the Orchestration model is very similar as well.
And that's it. Nothing incredibly complicated. Obviously you'll want to code additional functionality (write out to a log file, for example) to tailor to your specific needs. As a side note, a wonderful tool which helped me discover most BizTalk WMI objects is the PowerShell WMI Explorer.
Part 3 will cover Host Instances.
So the first thing I'd like to check are the Receive Locations and the Send Ports. I want to create this in a script so I can run this at-will. There are a few ways to do this: NotePad being the most basic, or we could download the PowerShell ISE. But my favorite is SAPIEN PowerShell Studio. I'm still trying to figure out why Microsoft hasn't tightly integrated this kind of functionality to Visual Studio.
So back to the scenario. The object to use in both cases is the Microsoft.BizTalk.ExplorerOM.BtsCatalogExplorer:
You may notice the hard way that this object is a 32-bit only object. So, if you are running in a 64-bit mode of PowerShell, your script won't run. You will need to force 32-bit mode. This can be done with the following:
The above two snippets are the basis of setting up both Receive Locations and Send Ports. I'll first focus on the Send Ports. The first thing is to instantiate an object using the BizTalk Explorer Object Model. Once that's done, we'll need to connect to the proper BizTalk database. After that's done, it's a simple loop to go through each Send Port:
Receive Locations are nested one level deeper than Send Ports, otherwise they are essentially the same process.
And (surprise, surprise) the Orchestration model is very similar as well.
And that's it. Nothing incredibly complicated. Obviously you'll want to code additional functionality (write out to a log file, for example) to tailor to your specific needs. As a side note, a wonderful tool which helped me discover most BizTalk WMI objects is the PowerShell WMI Explorer.
Part 3 will cover Host Instances.
Subscribe to:
Posts (Atom)