Showing posts with label FAQ. Show all posts
Showing posts with label FAQ. Show all posts

Thursday, March 24, 2011

Basics - How to confirm a Biztalk update

Here are the version numbers of current Biztalk 2006 R2 as seen at Microsoft.

BizTalk Server 2006 R23.6.1404.0
BizTalk Server 2006 R2 SP13.6.2149.10January 27th, 2010
Cumulative Update 1 (CU1)3.6.2210.12April 12th, 2010
Cumulative Update 2 (CU2)3.6.2217.12June 24th, 2010
Cumulative Update 3 (CU3)3.6.2224.12August 30th, 2010


For other Biztalk versions you can explore another Microsoft Link.

We made an update on Biztalk to CU3 and the version seen at About was still 3.6.2149.10, referring to the SP1.



To know the specific add-ons like CU's, and hotfixes, the only place to go is Add and Remove Programs. Just remember to mark the Show Updates. checkbox.

Friday, January 21, 2011

Using Business Rules Engine (I)

Making business rules without messages


The most common way of using business rules is by evaluating a XML message with XPath and return an XML message with more info. The problem is that most of the examples are orchestration dependents: by demanding a compiled DLL with the schemas to be used, they limit the possibilities.
In a project with many orchestrations an easy solution is to make a solution with the schemas, compile, define the rules based on that DLL, and then apply them in the remaining solutions. If it is a small project where schema and orchestration could be on the same DLL, a first compilation is needed for BRE to access the schema. Only then the orchestration can add the rule.

But, what if the message is not important in any direction? What if you just want to use the same rule in all orchestrations without referring each and every DLL?
Scenario: ten distinct schemas. One flow in and one flow out for each. The same tracking rules apply on each direction, depending only on the schema. Here I found a great way of corrupting the principles of the rules.
I recommend this blog because it was the first were I could find any comprehensible info about BRE.

Basic: Policies have versions, on each version one or more rules. By activating different versions different rules can be in use. A rule is divided in condition and actions. A straight-forward "If-Then".

BRE Policy, Versions, Rules


Usually each orchestration has its own rule and each rule is for an orchestration, a direct match.
The trick is to make a single rule, the if always true, and the orchestration will receive information that can be used or not.

The advantage of business rules engine is the low processing time and the changeable ease (copy version, edit, publish and deploy). There are no big processing advantages in using rules this way, but the changing method is still easy and no deployments required.

Making the if always true


Like always, just use the condition 1==1 or something that obvious.
On the actions list, we’ll use an ArrayList to return a list of words.
  • Go to facts explorer window
  • Select .NET classes
  • Right-click and browse .NET Assemblies
  • Select the mscorlib library
  • Press OK

    BRE Search Library


    The library will become available.

    BRE ArrayList Add


    Find ArrayList and the Add() method, and drag it to actions pane as many time as you’ll need.
    Fill in with the key strings and publish the version.

    BRE Actions


    Add to the orchestration variables list one of type ArrayList.
    Go to Orchestration View and right click Variables folder for New Variable
    At new variable define name (in this example rulesArray) and type (<.NET Class…>, mscorlib, ArrayList)
    Create another variable, of type Boolean called generateAck.
    Add Call Rules component and use that variable as destination for the output.

    BRE Cal Rules


    And then at a Expression editor, search for the value and do as you please. In this example, only for the flows listed we’ll generate Ack. The fixed value is the message type that the orchestration mandatorily knows.

    Expression Editor


    For instance we are searching for Purchase Orders, abbreviated PO. Since the rulesArray includes that value, ANY orchestration that has Purchase Orders will set generateAcks as true and therefore record Acks, if the proper code is made.
  • Friday, September 18, 2009

    WCF service publishing wizard settings

    Did you ever had to republish a web service over and over again? Is it fun to go through the wizard and add the methods one by one?

    We were having that problem. The idea was to make a connection between SAP and Sharepoint through web services created by Biztalk. An RFC in SAP receives the request and returns the values to Sharepoint that will use them to create a page. To comunication was quick and stable, but I was losing my mind and time creating the services one by one. Let's see the process step by step with focus on Biztalk:

    1. the new RFC is created in SAP (not my problem)
    2. Biztalk imports reference with the SAP Adapter (easy)
    3. build and deploy dll (too easy)

    4. recreate service through Biztalk WCF Publishing Wizard
    4.1 select Transport Type
    4.2 enable Metadata endpoint
    4.3 select Biztalk application
    4.4 select "publish schemas"
    4.5 rename Web Service
    4.6 rename Web Method
    4.7 define schema type for request and for response, enlarging both the columns to read the schema type
    4.8 repeat 4.6 and 4.7 for every single RFC, old or new...
    4.9 define namespace
    4.10 define the same service location with overwrite
    4.11 allowing anonymous access
    4.12 press Create

    5 update reference on client
    6 do some new methods
    7 test

    The best way to reduce time on Biztalk is never to press the Finish button. Going back the settings are all there and you can deploy it again.

    But there is a better way... I googled for this situation. On this blessed link I found the answers for all my problems. Well, at least for this one.
    So, the deployment stores the configuration inside wwwroot. And more! It is understandable and can be edited!

    I simply made a batch file to call the wizard with the parameter
    cd C:\Program Files\Microsoft BizTalk Server 2006\
    BtsWcfServicePublishingWizard -WcfServiceDescription=C:\Inetpub\wwwroot\BizTalkWcfService\App_Data\Temp\WcfServiceDescription.xml

    and now my work is just with steps 4.3, 4.4, 4.6, 4.7, 4.9, 4.12. The annoying configuration of all old methods, and more than half the checkbox clicks are made for me.

    Question: Shouldn't the wizard allow the loading of a xml file?

    Friday, December 5, 2008

    Defining new filenames for send handler

    How to create more ellaborated filename?


    Following the list of predefined file names given on my previous post, how can you get more than what Biztalk gives you?

    Solution:


    You can change the SourceFileName. In the construct message block of the orchestration use something like the following:

    Message_2 = Message_1;
    Message_2(FILE.ReceivedFileName) = "your_value"+ToString(Message_1.id);

    And then when you are defining the send port use File Name as usually: %SourceFileName%

    List of variables for naming files at in send handler


    How to change file name


    This isn't a trouble, but a useful information that should be on every biztalk programmer manual.

    The name of the file generated, mainly for archiving porposes, sometimes should be more than a GUId. This is a complete list of all the variables that can be used at the send handler. This is only valid for writing files, and some of them are only available when the input comes from a file also.


    Macro nameSubstitute value
    %datetime%Coordinated Universal Time (UTC) date time in the format YYYY-MM-DDThhmmss (for example, 1997-07-12T103508).
    %datetime_bts2000%UTC date time in the format YYYYMMDDhhmmsss, where sss means seconds and milliseconds (for example, 199707121035234 means 1997/07/12, 10:35:23 and 400 milliseconds).
    %datetime.tz%Local date time plus time zone from GMT in the format YYYY-MM-DDThhmmssTZD, (for example, 1997-07-12T103508+800).
    %DestinationParty%Name of the destination party. The value comes from message the context property BTS.DestinationParty.
    %DestinationPartyID%Identifier of the destination party (GUID). The value comes from the message context property BTS.DestinationPartyID.
    %DestinationPartyQualifier%Qualifier of the destination party. The value comes from the message context property BTS.DestinationPartyQualifier.
    %MessageID%Globally unique identifier (GUID) of the message in BizTalk Server. The value comes directly from the message context property BTS.MessageID.
    %SourceFileName%Name of the file from where the File adapter read the message. The file name includes extension and excludes the file path, for example, foo.xml. When substituting this property, the File adapter extracts the file name from the absolute file path stored in the FILE.ReceivedFileName context property. If the context property does not have a value, for example, if message was received on an adapter other than File adapter, then the macro will not be substituted and will remain in the file name as is (for example, C:\Drop\%SourceFileName%).
    %SourceParty%Name of the source party from which the File adapter received the message.
    %SourcePartyID%Identifier of the source party (GUID). The value comes from the message context property BTS.SourcePartyID.
    %SourcePartyQualifier%Qualifier of the source party from which the File adapter received the message.
    %time%UTC time in the format hhmmss.
    %time.tz%Local time plus time zone from GMT in the format hhmmssTZD (for example, 124525+530).