Tuesday, November 29, 2005

New functions in BizTalk 2006 Rule Editing

There is an excellent blog article writen by Richard Seroter on how to enable static methods in the BizTalk 2006 rule engine. Seems that for the time being you have to get into the registry. I wonder why these essential functions are always hidden? Are there any caveats?

You can read it here

Let's see if it will make it into the the final release. This would eliminate the need for all these simple .NET conversion functions that are needed currently with BizTalk 2004. No need to wrap it in an IFactCreator, and no need to create an instance to test the rules.

Monday, November 14, 2005

New features in the Policy Verificator


Acumen Business has announced the next release of the Policy Verificator. The 1.3 release contains some interesting new features
1. Generation of a full rule dependency network graph.

ThumbCarDiagnosis_DependencyGraph.png


2. Interactive rule dependency Graph


ThumbCarDiagnosis_InteractiveRuleMap.png

There is also a gettingstarted page that guides you through one of the examples.


You can download the product here

Wednesday, October 05, 2005

RPC server is unavailable

SSO -> RPC server is unavailable.

I had problems with the Single Sign On (SSO) to get authentication to execute a SOAP request (or so I thought)
In one of my actions of trying to resolve it, I tried to reset the SSO server name to the machine name. This is something I absolutely should not have done!


C:\Program Files\Common Files\Enterprise Single Sign-On>ssomanage.exe –serverall Namgang

C:\Program Files\Common Files\Enterprise Single Sign-On>ssomanage.exe –server Namgang


This did result in the error “The RPC server is unavailable” for almost all of the ssomanage.exe and ssoconfig.exe commands:



C:\Program Files\Common Files\Enterprise Single Sign-On>ssomanage.exe -displaydb
Using SSO server : sso

SQL Server                                               : namgang
SSO database                                             : ssodb

ERROR: 0x800706BA : The RPC server is unavailable.



The google searches on “RPC server is unavailable” and “BizTalk”  or “SSO” did not give me any clue what kind of trouble I just created. So here is my little contribution for others:

I thought the SSO server name would be my machine name, but after hours (almost days) I found out that the original sso server name was not my machine name, but the IP address!
I found this by running the rpcdump.exe utility. After resetting the SSO server name to the IP address for –serverall and –server, I had it up and running again.

C:\Program Files\Common Files\Enterprise Single Sign-On>ssomanage.exe -server 192.168.1.101
The operation completed successfully.

C:\Program Files\Common Files\Enterprise Single Sign-On>ssomanage.exe -serverall 192.168.1.101
The operation completed successfully.


C:\Program Files\Common Files\Enterprise Single Sign-On>ssomanage.exe -displaydb
Using SSO server : 192.168.1.101

SQL Server                                               : namgang
SSO database                                             : ssodb
SSO secret server name                                   : NAMGANG
SSO Admin account name                                   : SSO Administrators
SSO Affiliate Admin account name                         : SSO Affiliate Administrators
Size of audit table for deleted applications             : 1000
Size of audit table for deleted mappings                 : 1000
Size of audit table for external credential lookups      : 1000
Ticket timeout (in minutes)                              : 2
Credential cache timeout (in minutes)                    : 60
SSO status                                               : Enabled
Tickets allowed                                          : No
Validate tickets                                         : Yes



Sent the rpddump.exe to a output.txt file, and you can examine the dump with notepad.


C:\Program Files\Resource Kit>rpcdump.exe /V > output.txt


Or look specific at an IP address and notice the SSO servers

C:\Program Files\Resource Kit>rpcdump.exe /s 192.168.1.101
Querying Endpoint Mapper Database...
78 registered endpoints found.

ncacn_ip_tcp(Connection-oriented TCP/IP)
  192.168.1.101[1030] [1b6a54d8-0f2a-47b2-b934-e876b711eb19] SSOSecretServer :NOT_PINGED
  192.168.1.101[1030] [87632da4-2f1c-4e92-953a-41306b36c095] SSOCSServer :NOT_PINGED
  192.168.1.101[1030] [87a18bff-b7a4-4d79-a996-b9811cd73c94] SSOLookupServer :NOT_PINGED
  192.168.1.101[1030] [416767be-be19-433e-91c3-4ad2ed88dede] SSOAdminServer :NOT_PINGED
  192.168.1.101[1030] [906b0ce0-c70b-1067-b317-00dd010662da]  :NOT_PINGED
  192.168.1.101[1030] [fe1bcf2e-700c-47ca-b47b-7d1c8688307f] SSOMappingServer :NOT_PINGED
  192.168.1.101[1025] [82ad4280-036b-11cf-972c-00aa006887b0]  :NOT_PINGED

              […deleted…]

rpcdump.exe completed sucessfully after 1 seconds

Thursday, September 29, 2005

Scalable Vector Graphs

I've been searching a long time how to draw a diagonal line with just standard Web features (HTML, CSS, DIV, etc). Most of the time I end up at Scalable Vector Graph (SVG). However there has not been a wide spread support for this technology on the client side. Microsoft is betting it's money on it's 'own' standard Avalon.

The W3C has one little note, that diagonal layout might be done without SVG, but the follow up link to these details is broken.

Today to my pleasant surprise, I stumbled on the information that Mozila has native support for SVG! This is opening a big door to get .SVG files to the clients desktop. Here is a view of a rule network dependency graph. Probably of more interest is the automatic detected rule contradiction. This rule anomaly was detected by the Policy Verificator that supports rendering SVG files.

For those stuck with Internet Explorer: you can view .SVG files with the Adobe plugin.

Tuesday, September 20, 2005

BizTalk Rules engine scalibility

When exploring different rule base vendors, you probably encounter references to the RETE algorithm by Charles Forgy. This algorithm has proven itself to scale well for very large ruleset.
In all my years of experience, I've never encountered a client with more than 500 rules in a single rule policy. The reason is not any scalability issues on inference engines. The reason is simple. It is difficult for a business expert to
  • manage a very large rule policy
  • maintain a very large rule policy
  • verify and validate a large rule policy

As with any complexity, the divide and conquer strategy works very well. Split the large policy into smaller parts.
But for those who like to push the limits and see how well the BizTalk inference engine scales, you might like to read the article Microsoft'’s Rule Engine Scalability Results - A comparison with Jess and Drools, by Charles Young.

BizTalk Throughput and Capacity Tester

In the category essential tools for the BizTalk consultant; here we have the Throughput and Capacity Tester made by Larry Beck. What else can we ask for?

Update: The new release has been renamed to BTSPerfTester 1.0

The BizTalk Performance Tester (the Tester) is an application intended to assist architects and developers quantify the performance characteristics of their BizTalk solutions. The application meets this objective by performing stress tests against the target solution and monitoring the application performance.

Saturday, April 16, 2005

Policy Verificator 1.1 released

Acumen Business released the Policy Verificator version 1.1. An all new UI is designed what should significantly increase the usability issues from the initial release. Specially of interest is the inclusion of Datetime support for rule verification as well as support for the standard Microsoft Biztalk functions and predicates.

Wednesday, March 30, 2005

log4net - 1.2.9 Beta release

Log4net development is showing signs of life! After a long period of silence the 1.2.9 Beta has been released. Some highlights of the list of new features:
  • New logging contexts
    • GlobalContext
    • ThreadContext
    • LogicalThreadContext
    • LoggingEvent
  • .NET string formatting syntax
  • Customizable levels
  • RollingFileAppender roll once
  • SmtpAppender authentication
  • ... and more

Wednesday, March 16, 2005

Instrumentation - Logging

I started of with log4j in my Java days, and was quick with adopting another fine .NET port: log4net.

But for work, we had to consider Microsofts Enterprise Instrumentation Framework (EIF). But a little more reading revealed that this package is getting replaced with the newly designed Enterprise Library. This framework not only contains Logging, but also a design pattern for Configuration, Data Access, Exception handling, Security, etc.

The Enterprise Library is all looking pretty o.k. but it seemed to be overly designed, over complicated and getting pretty slow. Also on migrating from one Microsoft packages to another: there is no migration path. And no support is mentioned for the future. Seems like this is going for a Corba-death: Beautifully designed, complicated to use, and slow.
For a comparison overview see Daniel Cazzulino's EIF vs log4net feature comparison char

I always like fast and simple. So that takes me back to log4net. The only concern I have with log4net is that the latest view builds on Sourceforge all refer to beta releases that seems to be quite dated. But till so far I never had any issues with this latest beta release.

Scott Colestock also has been writing how log4net can be integrated with Biztalk 2004. So what else are we waiting for. Let me put in my 2 cents for some documentation on the conversionPattern:

The conversionPattern format

The conversion pattern is closely related to the conversion pattern of the printf function in C. A conversion pattern is composed of literal text and format control expressions called conversion specifiers.

You are free to insert any literal text within the conversion pattern.

Each conversion specifier starts with a percent sign (%) and is followed by optional format modifiers and a conversion character. The conversion character specifies the type of data, e.g. category, priority, date, thread name. The format modifiers control such things as field width, padding, left and right justification. The following is a simple example.



<appender name="FileAppender" type="log4net.Appender.FileAppender">
<file value="c:\\log\\My.log">
<appendtofile value="true">
<layout type="log4net.Layout.PatternLayout">
<conversionpattern value="%-5p [%t]: %m%n"/>
</layout>
</appender>

Then the statements


private static readonly log4net.ILog log = log4net.LogManager.GetLogger(typeof(MyType));
log.Debug("Message 1");
would yield the output
DEBUG [MyType]: Message 1

Note that there is no explicit separator between text and conversion specifiers. The pattern parser knows when it has reached the end of a conversion specifier when it reads a conversion character. In the example above the conversion specifier %-5p means the priority of the logging event should be left justified to a width of five characters. The recognized conversion characters are


Conversion Character Effect
c Used to output the category of the logging event. The category conversion specifier can be optionally followed by precision specifier, that is a decimal constant in brackets.

If a precision specifier is given, then only the corresponding number of right most components of the category name will be printed. By default the category name is printed in full.

For example, for the category name "a.b.c" the pattern %c{2} will output "b.c".

C Used to output the fully qualified class name of the caller issuing the logging request. This conversion specifier can be optionally followed by precision specifier, that is a decimal constant in brackets.

If a precision specifier is given, then only the corresponding number of right most components of the class name will be printed. By default the class name is output in fully qualified form.

For example, for the class name "org.apache.xyz.SomeClass", the pattern %C{1} will output "SomeClass".

WARNING Generating the caller class information is slow. Thus, it's use should be avoided unless execution speed is not an issue.

d Used to output the date of the logging event. The date conversion specifier may be followed by a date format specifier enclosed between braces. For example, %d{HH:mm:ss,SSS} or %d{dd MMM yyyy HH:mm:ss,SSS}. If no date format specifier is given then ISO8601 format is assumed.

The date format specifier admits the same syntax as the time pattern string of the SimpleDateFormat. Although part of the standard JDK, the performance of SimpleDateFormat is quite poor.

For better results it is recommended to use the log4j date formatters. These can be specified using one of the strings "ABSOLUTE", "DATE" and "ISO8601" for specifying AbsoluteTimeDateFormat, DateTimeDateFormat and respectively ISO8601DateFormat. For example, %d{ISO8601} or %d{ABSOLUTE}.

These dedicated date formatters perform significantly better than SimpleDateFormat.

F Used to output the file name where the logging request was issued.

WARNING Generating caller location information is extremely slow. It's use should be avoided unless execution speed is not an issue.

l Used to output location information of the caller which generated the logging event.

The location information depends on the JVM implementation but usually consists of the fully qualified name of the calling method followed by the callers source the file name and line number between parentheses.

The location information can be very useful. However, it's generation is extremely slow. It's use should be avoided unless execution speed is not an issue.

L Used to output the line number from where the logging request was issued.

WARNING Generating caller location information is extremely slow. It's use should be avoided unless execution speed is not an issue.

m Used to output the application supplied message associated with the logging event.
M Used to output the method name where the logging request was issued.

WARNING Generating caller location information is extremely slow. It's use should be avoided unless execution speed is not an issue.

n Outputs the platform dependent line separator character or characters.

This conversion character offers practically the same performance as using non-portable line separator strings such as "\n", or "\r\n". Thus, it is the preferred way of specifying a line separator.

p Used to output the priority of the logging event.
r Used to output the number of milliseconds elapsed since the start of the application until the creation of the logging event.
t Used to output the name of the thread that generated the logging event.
x Used to output the NDC (nested diagnostic context) associated with the thread that generated the logging event.
X

Used to output the MDC (mapped diagnostic context) associated with the thread that generated the logging event. The X conversion character must be followed by the key for the map placed between braces, as in %X{clientNumber} where clientNumber is the key. The value in the MDC corresponding to the key will be output.

% The sequence %% outputs a single percent sign.

By default the relevant information is output as is. However, with the aid of format modifiers it is possible to change the minimum field width, the maximum field width and justification.

The optional format modifier is placed between the percent sign and the conversion character.

The first optional format modifier is the left justification flag which is just the minus (-) character. Then comes the optional minimum field width modifier. This is a decimal constant that represents the minimum number of characters to output. If the data item requires fewer characters, it is padded on either the left or the right until the minimum width is reached. The default is to pad on the left (right justify) but you can specify right padding with the left justification flag. The padding character is space. If the data item is larger than the minimum field width, the field is expanded to accommodate the data. The value is never truncated.

This behavior can be changed using the maximum field width modifier which is designated by a period followed by a decimal constant. If the data item is longer than the maximum field, then the extra characters are removed from the beginning of the data item and not from the end. For example, it the maximum field width is eight and the data item is ten characters long, then the first two characters of the data item are dropped. This behavior deviates from the printf function in C where truncation is done from the end.

Below are various format modifier examples for the category conversion specifier.

Format modifier left justify minimum width maximum width comment
%20c false 20 none Left pad with spaces if the category name is less than 20 characters long.
%-20c true 20 none Right pad with spaces if the category name is less than 20 characters long.
%.30c NA none 30 Truncate from the beginning if the category name is longer than 30 characters.
%20.30c false 20 30 Left pad with spaces if the category name is shorter than 20 characters. However, if category name is longer than 30 characters, then truncate from the beginning.
%-20.30c true 20 30 Right pad with spaces if the category name is shorter than 20 characters. However, if category name is longer than 30 characters, then truncate from the beginning.

Below are some examples of conversion patterns.

%r [%t] %-5p %c %x - %m\n
This is essentially the TTCC layout.
%-6r [%15.15t] %-5p %30.30c %x - %m\n
Similar to the TTCC layout except that the relative time is right padded if less than 6 digits, thread name is right padded if less than 15 characters and truncated if longer and the category name is left padded if shorter than 30 characters and truncated if longer.



References:

make files explained if you did not grew up with them

Here is a nice post on how to define makefiles for a go project and actually teaching you some makefile constructs: https://sahilm.com/mak...