Hi All,
Yesterday I have cleared the Microsoft certification on BizTalk Server 2006 (70-235). It’s a great relief after some good hard work.
Cheers
M.R.ASHWINPRABHU
Monday, 12 May 2008
Sunday, 4 May 2008
MoM - Consolidation and Timer based rule
I have a requirement to create a MoM rule which would automate a task based on some specific eventlog entires in production servers. The automatic task is to recycle some of the COM+ components based on the eventlog. So the eventlog entry is the evidence for me to identify that the issue has occurred. I am going not going to talk about the scripts which I have used to restart the COM+ componet but how I have configured the MoM rule for the same.
So I have to create a MoM rule which would monitor the production server and perform the resolution activity. But the crux is to perform the resolution activity only when the continuous 5 entries of the eventlog are identified in the span of 30 seconds in the production server. So I have to create MoM rule which should act based on the number of the entries of an event in the given time window.
I have achieved this by creating an event-rule which would monitor the specified eventlog for the “Repeat Count” of 5 and I have created another consolidation rule which would maintain a counter for event-rule in 30 seconds. This counter will be reset to zero, if the specified count of logs doesn’t met in specified period (30 seconds). i.e. if the application logs 4 event entries for the specified criteria in 30 seconds. The event-rule’s repeat count would be set back to 1. But if the application logs event entry for 5 times in 30 seconds (or in lesser than 30 seconds), the event-rule’s response entries would trigger.
Following are the snapshot of the MoM rules:
Figure 1: Event-rule for the event entry of 5 entries.
Figure 2: Consolidation rule for 30 seconds.
Monday, 28 April 2008
MoM (Microsoft Operations Manager) Design
We have been using MoM (Microsoft Operations Manager) in our BizTalk projects for operational support purposes. I am already very much impressed with the advantages it provides for any Wintel applications in its production support arena. Few months back I got an opportunity to design another MoM package for a messaging product based out of Java for Windows environments. The messaging product has been in use for nearly a year in our customer’s production environment.
When I mean by messaging product, we can’t not compare its capabilities with BizTalk, as it doesn’t perform any business processing upon the messages while transferring the messages. But its intended objective is to just transfer very large files in very high frequency to different platform like UNIX, Mainframe etc. This product is yet to evolve in many ways for an enterprise usage as we all know no application is complete in this universe.
Our customer was already using an in-house operational tool to handle transfer failures (and also to handle the products open issues). This product has very minimal capability in throwing/publishing the exceptions (file transfer failures). Any transfer failures from this product would be simply logged in the event log with same Event ID, Event Category, Event Source and the only difference is the description of the error. Our customer is using an alert monitor tool, which provides the dashboard sort of view to the 1st line support. So, all the operation tools should provide their output to dashboard tool. They call that tool as Mangers of Manger.
Exceptions in this messaging scenario can be like:
· File not found at source.
· Configured pattern of files are not available for transfer.
· Configured file path / server unavailability.
· File has been occupied by another process
· Server disk space full
· Staging folders maintenance issues
· Many product related issue
· Unknown.
Currently used operational tool doesn’t have the intelligence to classify the exception and act accordingly/show the classified alerts to the Monitoring tool. So the challenge is to create an efficient MoM-package which would identify the different categories of the alerts and give the output accordingly to the Managers of manager tool.
I have classified the exception as below:
The exceptions are classified into different category since each category requires different actions:
- Subscriber issues require Call-out to the Subscriber production-support team.
- Messaging service issue requires Call-out to our production team.
- Product issue requires some workarounds which can be automated again using MoM.
- Off course we can’t always capture all the exceptions, so a generic catch to capture these exceptions also and throw them with lower severity to the monitoring tool.
In MoM with its ability to use custom scripts, I have configured the categories of the exceptions, by throwing them with Custom Exception Number and Custom event description lets say exception category appended at the starting of the every event description. So I have configured a generic alert called “Event-Filter” which swallows all events from the application. In the event-filter I have used a script which would read the event description and in turn throws another alert with different event ID(specific to category) and the event category append in the event description. For example: if the exception is “File not found”
The messaging product would throw the exception as following in the event log:
Event Type : Error Event Source : ABCD Event Category : None Event ID : 123 (Always same for all error) Date : 28/04/2008 Time : 15:21:48 User : Computer : DummyMach123 Description : Files not found at the configured path \\mshsrmsappp0008\P1102747\TestFile.txt> |
This event log would be swallowed by the Event-Filter script to throw a MoM event:
Event-ID: 1001 (Custom defined) Event Category: Subscriber Event-Decription: Event_Category [Subscriber]: Files not found at the configured path file:////mshsrmsappp0008/P1102747/TestFile.txt |
And for the alerts which came out of the event-filter I have configured a rule to action the category related actions. So the new MoM-package would enable the application to behave something like the following:
Following is the part of the event-filter script which is in if-condition, checks the event description and calls another function (CreateEvent) to throw the event with different event criteria’s.
If InStr(strParentEvtDesc,strSCNoMatchPattern) Then 'match the pattern strParentEvtDesc= strECSubscriber & objContextEvent.Message CreateEvent EVENT_ID_NoMatchPattern,EVENT_TYPE_ERROR,SCRIPT_EVENTSOURCE,strParentEvtDesc Elseif… |
Following is the method used to throw the event from event-filter:
Sub CreateEvent(intEventNumber,intEventType,strEventSource,strEventMessage) Set objEvent = ScriptContext.CreateEvent() objEvent.EventSource = strEventSource objEvent.EventNumber = intEventNumber objEvent.EventType = intEventType objEvent.Message = strEventMessage ScriptContext.Submit objEvent End Sub |
Following is the event rule in MoM for the subscriber related issue and marked is the criteria for the rule:
As you would have noticed, in the new-MoM package design diagram (showed above) I have showed a XML- file next to the subscriber issues box. Okay I am able to classify the exceptions and now what I am going to do with it? If it’s a subscriber related issue, as I mentioned earlier we want throw a MoM alter which would contain the details of the specific subscriber. I am going to maintain the subscriber contacts in the XML file which can be used a configuration file for the alert for my subscriber related issues. How I am going to accomplish this requirement? We will see it in another day.
Special Thanks to Mr.Lee Nichol for whatsoever little knowledge I have in MoM
Monday, 24 March 2008
IProbeMessage interface in BizTalk.
If the pipeline component's execution mode is set as "First recognized" or "All recognized", Pipeline Manager iterate through all the components in the stage to find a component which has implemented IProbeMessage interface; then it executes that component leaving others in First recognized mode and executes all the components that recognise the format of the data in the All recognized mode. i.e. IProbeMessage interface enables the pipeline component to decide do they want to process the message or not.
In BizTalk pipeline, there is concept called Message Probing. This means pipeline component intercepts (probes) the message and determine the format of the message. Disassemble stage's message probing capability enables it receive different format of the message to be received from same endpoint, enables it to identify the format of the message that is being processed dynamically.
IProbeMessage interface contains a method Probe which returns true if the disassembler decides to process the message. Probe method read firs few bytes of the message data stream in order to decide whether it is capable of processing the message or not.
public interface IProbeMessage
{
bool Probe(IPipelineContext pContext, IBaseMessage pInMsg);
}
Sunday, 2 March 2008
Adapter version details under host process domain.
Our production support guys came up with an interesting requirement, How to find the version of the custom BizTalk adapter assembly being executed under particular host. This has to be achieved without disturbing the production servers.
The answer is pretty simple, use the Process Explore (procexp.exe). One of the gems from SysInternal (Acquired by Microsoft). Process Explore doesn’t require installation, just works with the XCOPY of the procexp.exe as many of the SysInternals tools (satisfied our ChangeManagement since this doesn’t require any installation in the production server :) )
- Start it up…
- In the View menu, ensure that Show Lower Pane option is checked
- In the View\Lower Pane View submenu choose DLLs
- Highlight the relevant BTSNTSvc.exe process in the upper pane
- Locate your adapter’s runtime assembly and you can get the version details
Process Explore: http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx
PS: Assemble name has been hidden for companies privacy. And Thanks for Chris Dickson in helping us.
Technorati Tags: BizTalk
Wednesday, 27 February 2008
Oslo, BizTalk Mapper & Surface – Fjord
I came across a very interesting initiative from Microsoft and thought of blog it. It is about Microsoft's Fjord.
Fjord is the code name for the Microsoft Surface integration pieces to the Modeling commitments of Oslo. BizTalk Mapper, a BizTalk component is the first piece of Oslo to be integrated with Surface.
As Oslo’s one of the key focus is going to be on Modeling, I am expecting the orchestration designer can also be integrated with the Microsoft’s surface(lets see). For expression or for the editor requirement, they may come up with Tablet-PC kind of the keyboard in Surface for Orchestration. More surprises and wonders can be expected as part of Oslo.
Fjord – The code name for BizTalk mapper’s integration with Surface. As fjord means a long, narrow bay with steep sides from the top region of the mountains to the sea, the source schema and destination schema on the two sides on the functoids in the BizTalk Map could have resembled as mountains in the two side of the sea. Aptly named.
And another interesting fact about the Microsoft’s Fjord and Mother Nature’s fjord is Norway has got many deep fjords. Again I donn know why Microsoft’s Oslo is more linked with Norway (Norway’s capital is Oslo).
Reference:
Subscribe to:
Posts (Atom)
