Running both Windows 7 and Windows 8 in a MacBook Pro

Last month I updated my main laptop MacBook Pro to Windows 8 and I’ve written about the experience here "Installing Windows 8 on MacBook Pro experience".  There are no noticeable issues and I’m quite pleased with it. Even though technically all of the applications that run in Windows 7 should run on Windows 8, still […]

The post Running both Windows 7 and Windows 8 in a MacBook Pro appeared first on BizTalk360 Blog.

Blog Post by: Saravana Kumar

BizTalk maps with two inputs – Complement, Intersect and Union of Sets

BizTalk maps with two inputs – Complement, Intersect and Union of Sets

Union In set theory, the union (denoted by %u222a) of a collection of sets is the set of all distinct elements in the collection. It is one of the fundamental operations through which sets can be combined and related to each other. (http://en.wikipedia.org/wiki/Union_(set_theory)). For example, if A = {1, 2, 3, 4, 5, 6, 7} […]
Blog Post by: mbrimble

WCF SQL operations

Normal
0

false
false
false

EN-AU
X-NONE
X-NONE

MicrosoftInternetExplorer4

/* Style Definitions */
table.MsoNormalTable
{mso-style-name:”Table Normal”;
mso-tstyle-rowband-size:0;
mso-tstyle-colband-size:0;
mso-style-noshow:yes;
mso-style-priority:99;
mso-style-parent:””;
mso-padding-alt:0cm 5.4pt 0cm 5.4pt;
mso-para-margin-top:0cm;
mso-para-margin-right:0cm;
mso-para-margin-bottom:10.0pt;
mso-para-margin-left:0cm;
line-height:115%;
mso-pagination:widow-orphan;
font-size:11.0pt;
font-family:”Calibri”,”sans-serif”;
mso-ascii-font-family:Calibri;
mso-ascii-theme-font:minor-latin;
mso-hansi-font-family:Calibri;
mso-hansi-theme-font:minor-latin;
mso-bidi-font-family:”Times New Roman”;
mso-bidi-theme-font:minor-bidi;
mso-fareast-language:EN-US;}

When adding WCF sql ports to BizTalk, you can add a whole
host of different types of operation with SQL and it’s incredibly powerful. 
The problem is with all these options, the wizard rarely
makes a binding file for you, it will make the schemas, but the binding file
contains that extra little bit of magic

The key to all of this in the SOAP action header you specify on the port.
There are your basic ones:
TableOp/Insert/dbo/Employee
TableOp/Update/dbo/Employee
If you read this, it will do a table operation and insert or
update employee record(s) in the employee table.

Then there is of course stored procedures for both send and receive ports. 


TypedProcedure/dbo/StoredProcedureName

Simple enough, however maybe you have a few operations you
want to do, you want to go for a more composite operation. 
Your Soap action can be CompositeOperation
The message you send can do a whole host of things, for
example, insert into a table, and when done, run a stored procedure.
You have your insert schema, and your execute stored
procedure schema, that the wizard generates, now bundle this into the following
structure and all of a sudden a whole world of opportunities opens up.
<xs:element name=Request>
    <xs:complexType>
      <xs:sequence>
        <xs:element
ref=ns0:Insert />
        <xs:element
ref=ns1:CompareEmployee />
      </xs:sequence>
    </xs:complexType>
  </xs:element>
  <xs:element
name=RequestResponse>
   <xs:complexType>
    <xs:sequence>
     <xs:element
ref=ns0:InsertResponse />
     <xs:element
ref=ns1:CompareEmployeeResponse/>
    </xs:sequence>
   </xs:complexType>
 
</
xs:element>
Then there are the Generic operations, vastly undocumented,
for example a SQL reader, that can execute SQL against the database and return
the results of the query
Your Soap Action header would be: GenericOp/ExecuteReader
The schema looks like this:
  <ExecuteReader
xmlns=http://schemas.microsoft.com/Sql/2008/05/GenericTableOp/>
    <Query>[PL/SQL
STATEMENT1];[PL/SQL STATEMENT2];</Query>
  </ExecuteReader>
Have a look at some of the more unknown options available, and you start to see the power in all of this. 

Operation
Soap Action
 Header
ExecuteNonQuery
Request
GenericOp/ExecuteNonQuery
ExecuteNonQuery
Response
GenericOp/ExecuteNonQuery/response
ExecuteReader
Request
GenericOp/ExecuteReader
ExecuteReader
Response
GenericOp/ExecuteReader/response
ExecuteScalar
Request
GenericOp/ExecuteScalar
ExecuteScalar
Response
GenericOp/ExecuteScalar/response

Refer to this link for more: http://msdn.microsoft.com/en-us/library/dd788372%28v=bts.10%29.aspx

BizTalk Innovation Day – London | 16th January 2013 – London, England

BizTalk Innovation Day – London | 16th January 2013 – London, England

After conducting this event across various major European cities: Amsterdam (Netherland), Milan (Italy), and Stavanger (Norway) since Feb 2011, it is really exciting to announce that the next event will take place in London – England on January 16, 2013! What is BizTalk Innovation Day/Event? BizTalk Innovation Day (BID) or sometimes called BizTalk Innovation Event […]
Blog Post by: Sandro Pereira

A Simple Entity Tagger

In the REST world, ETags are your gateway to performance boosts by letting clients cache responses. In the non-REST world, you may also want to add an ETag to an entity definition inside a traditional service contract – think of a scenario where a consumer persists its own representation of your entity, and wants to keep it in sync. Rather than load every entity by ID and check for changes, the consumer can send in a set of linked IDs and ETags, and you can return only the entities where the current ETag is different from the consumer’s version.

If your entity is a projection from various sources, you may not have a persistent ETag, so you need an efficient way to generate an ETag which is deterministic, so an entity with the same state always generates the same ETag.

I have an implementation for a generic ETag generator on GitHub here: EntityTagger code sample. The essence is simple – we get the entity, serialize it and build a hash from the serialized value. Any changes to either the state or the structure of the entity will result in a different hash. To use it, just call SetETag, passing your populated object and a Func<> which acts as an accessor to the ETag property:

EntityTagger.SetETag(user, x => x.ETag);

The implementation is all in at 80 lines of code, which is all pretty straightforward:

var eTagProperty = AsPropertyInfo(eTagPropertyAccessor);	
var originalETag = eTagProperty.GetValue(entity, null);
try
{	
	ResetETag(entity, eTagPropertyAccessor);	
	string json;
	var serializer = new DataContractJsonSerializer(entity.GetType());
	using (var stream = new MemoryStream())
	{
		serializer.WriteObject(stream, entity);
		json = Encoding.UTF8.GetString(stream.GetBuffer(), 0, (int)stream.Length);
	}
	var guid = GetDeterministicGuid(json);
	eTagProperty.SetValue(entity, guid.ToString(), null);
	//...

There are a couple of helper methods to check if the object has changed since the ETag value was last set, and to reset the ETag.

This implementation uses JSON to do the serializing rather than XML. Benefit – should be marginally more efficient as your hashing a much smaller serialized string; downside, JSON doesn’t include namespaces or class names at the root level, so if you have two classes with the exact same structure but different names, then instances which have the same content will have the same ETag. You may want that behaviour, but change to use the XML DataContractSerializer if you think that will be an issue.

If you can persist the ETag somewhere, it will save you server processing to load up the entity, but that will only apply to scenarios where you can reliably invalidate your ETag (e.g. if you control all the entry points where entity contents can be updated, then you can calculate and persist the new ETag with each update).

Integration Patterns with Azure Service Bus Relay, Part 3.5: Node.js relay

This is an extension to Part 3 in the IPASBR series, see also:

  • Integration Patterns with Azure Service Bus Relay, Part 1: Exposing the on-premise service
  • Integration Patterns with Azure Service Bus Relay, Part 2: Anonymous full-trust .NET consumer
  • Integration Patterns with Azure Service Bus Relay, Part 3: Anonymous partial-trust consumer

In Part 3 I said “there isn’t actually a .NET requirement here”, and this post just follows up on that statement. In Part 3 we had an ASP.NET MVC Website making a REST call to an Azure Service Bus service; to show that the REST stuff is really interoperable, in this version we use Node.js to make the secure service call.

The code is on GitHub here: IPASBR Part 3.5. The sample code is simpler than Part 3 – rather than code up a UI in Node.js, the sample just relays the REST service call out to Azure.

The steps are the same as Part 3:

  1. REST call to ACS with the service identity credentials, which returns an SWT;
  2. REST call to Azure Service Bus Relay, presenting the SWT;
  3. request gets relayed to the on-premise service.

In Node.js the authentication step looks like this:

    var options = { 
        host: acs.namespace() + '-sb.accesscontrol.windows.net', 
        path: '/WRAPv0.9/', 
        method: 'POST' 
    }; 

    var values = { 
        wrap_name: acs.issuerName(), 
        wrap_password: acs.issuerSecret(), 
        wrap_scope: 'http://' + acs.namespace() + '.servicebus.windows.net/' 
    }; 

    var req = https.request(options, function (res) { 
        console.log("statusCode: ", res.statusCode); 
        console.log("headers: ", res.headers); 
        res.on('data', function (d) { 
            var token = qs.parse(d.toString('utf8')); 
            callback(token.wrap_access_token); 
        }); 
    }); 
    req.write(qs.stringify(values)); 
    req.end();

Once we have the token, we can wrap it up into an Authorization header and pass it to the Service Bus call:

    token = 'WRAP access_token=\"' + swt + '\"';
    //...
                var reqHeaders = {
                    Authorization: token
                };

                var options = {
                    host: acs.namespace() + '.servicebus.windows.net',
                    path: '/rest/reverse?string=' + requestUrl.query.string,
                    headers: reqHeaders
                };

                var req = https.request(options, function (res) {
                    console.log("statusCode: ", res.statusCode);
                    console.log("headers: ", res.headers);
                    response.writeHead(res.statusCode, res.headers);
                    res.on('data', function (d) {
                        var reversed = d.toString('utf8')
                        console.log('svc returned: ' + d.toString('utf8'));
                        response.end(reversed);
                    });
                });
                req.end();

Running the sample

Usual routine to add your own Azure details into Solution Items\AzureConnectionDetails.xml and “Run Custom Tool” on the .tt files.

Build and you should be able to navigate to the on-premise service at http://localhost/Sixeyed.Ipasbr.Services/FormatService.svc/rest/reverse?string=abc123 and get a string response, going to the service direct.

Install Node.js (v0.8.14 at time of writing), run FormatServiceRelay.cmd, navigate to http://localhost:8013/reverse?string=abc123, and you should get exactly the same response but through Node.js, via Azure Service Bus Relay to your on-premise service. The console logs the WRAP token returned from ACS and the response from Azure Service Bus Relay which it forwards:

Azure: Sale that stopped the nationfor the wrong reason

You may have heard about ClickFrenzy where last night they launched a site with bargains
for a few hours.

Unfortunately there were far too many Error 500 – Server Too Busy errors
and hence the site lost many many potential customers.

Breeze has a great article on it – http://www.breeze.net/news/breezetalk/the-sale-that-stopped-the-nation,-enter-windows-azure.aspx

 

Who’d have thought.

Blog Post by: Mick Badran

BizTalk Business Rules Policies not caching .NET facts by default

BizTalk Business Rules Policies not caching .NET facts by default

While debugging a pipeline component that made use of a Business Rules Engine (BRE) policy I noticed some behavior that stopped me right in my tracks (funnily enough, I actually enjoy being surprised by BizTalk which never fails to please). Said component was asserting a .NET object into a BRE policy which contained multiple rules, […]
Blog Post by: Johann