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

BizTalk Community Series: Introducing Genuine Basil

The year 2012 has almost come to an end. Community wise it has been a fantastic year for BizTalk Server. Numerous new articles on the TechNet Wiki, blog posts on BizTalk 2013 (previously 2010 R2), and BizTalk related events taking place around the world. All of this is made possible by BizTalk community members. Genuine Basil is one of them and the following story is on him.

Genuine Basil, 30 years of age, was born in Kerala (an Indian state, also known as “God’s Own Country“). He migrated to Australia 2 years ago and is living with his beautiful wife Jis in Sydney.

Genuine’s overall IT experience is around 9 years and he has worked with some of the reputed organizations like Accenture, Wipro and CSC. He currently works as consultant at Burch Technologies,Sydney.

Genuine has around 7 years’ experience in BizTalk and worked with all versions of the product starting from BizTalk 2004. His main area of expertise is BizTalk development. Besides that he is also involved in design discussions and BizTalk server builds.

Genuine enrollment into the BizTalk world:

“I got trained in BizTalk while working at Accenture. I believe this was the turning point in my career. Being a BizTalk developer, it is important to have a good understanding about other technologies/standards you are integrating with, which means the learning opportunity is enormous. For me, the best thing about BizTalk is that every project is a new challenge and I am enjoying it.”

Genuine has the following to say about the community:

“First of all thanks to Steef-Jan for giving me this opportunity. BizTalk is blessed with its community members who are putting lots of effort to share their knowledge. I take this opportunity to thank all the community members for their contributions. Thank you !!”

In his spare time Genuine watches movies, soccer, and enjoys being with his family. He loves soccer and ManchesterUnited is his favorite team. He follows the EPL, ChampionsLeague and all other competitions, where Man United is involved. His long time dream is to visit Old Trafford one day. He hopes this day will come soon. In general Genuine likes to travel and explore new places.

Thanks Genuine for your time and contributions.

Cheers,

Steef-Jan

SP2013: Getting a Form Digest for Update REST calls

While on SharePoint 2013 training we came across all the different ways of calling
SharePoint and it’s data through JavaScript, JQuery and all the bits.

It was all looking good until we needed to update sharepoint – e.g.
a list, a list item etc.

The MS Course notes say – “if you’re in SharePoint you can get the Form Digest from
the main SharePoint Form.”

 

What about if you’re running outside of SharePoint (a Provider App – they now call
it, or Cloud Hosteddepending on who wrote the help article)

 

The answer in the notes is go and make an old fashion call to Sites.asmx
SOAP WebService.
from client side javascript this is going to be a feat.

.

The Answer – make a REST call to get the ’Context Info’ first, then
you’ll have the form digest and you’re done.

http://msdn.microsoft.com/en-us/library/fp142386(office.15).aspx#bk_synchronize (just
at the top of this page)

 

Table
1. SPContextWebInformation structure initialization properties

Property

Description

webFullUrl

Gets the server-relative URL of
the nearest site.

siteFullUrl

Gets the server-relative URL of
the root of the site collection that the site is contained within.

If the nearest web is the root
of a site collection, then the value of the webFullUrl property
is equal to the siteFullUrl property.

formDigestValue

Gets the server’s request form
digest.

LibraryVersion

Gets the current version of the
REST library.

SupportedSchemaVersions

Gets the versions of the schema
of the REST/CSOM library that are supported.

To access this information, use
the
/contextinfo operator.
For example:

http://server/web/doclib/forms/_api/contextinfo

To increase security against
cross-site scripting attempts, the
/contextinfo operator
accepts only POST requests.

Blog Post by: Mick Badran

Exploring REST Capabilities of BizTalk Server 2013 (Part 2: Consuming REST Endpoints)

Exploring REST Capabilities of BizTalk Server 2013 (Part 2: Consuming REST Endpoints)

In my previous post, I looked at how the BizTalk Server 2013 beta supports the receipt of messages through REST endpoints. In this post, I’ll show off a couple of scenarios for sending BizTalk messages to REST service endpoints. Even though the BizTalk adapter is based on the WCF REST binding, all my demonstrations are […]
Blog Post by: Richard Seroter