Things hard and not so hard.... RSS 2.0
# Monday, May 20, 2013

Well folks I’ve been greeted with the news that Microsoft Windows Azure will be in 2 geo-replicated places here on Australian soil, coming ‘shortly’.

As an Azure MVP & from Breeze (a leading Microsoft Cloud Partner) perspective we invest heavily in cloud technologies.

What does this mean and why should I care? I hear you ask… good question and I asked the same.

As most of you know I have a passion for Integration, sticking all sorts of things together from small RFID devices, hand made hand-held devices, raspberry PIs through to high end ERP, Financials & many other types of systems. So before I get to the WHY aspect, let me briefly set the context.

There’s some great data coming out of Gartner a report which caught my eye - http://searchsoa.techtarget.com/news/2240173583/Gartner-Better-collaboration-for-new-era-of-application-integration came out with these:

  • Integration Costs to rise by 33% by 2016, more than half of new system development costs will be spent on Integration
  • By 2017, over two-thirds of all new integration flows will extend outside the enterprise firewall.

So Integration just took on a whole new face – successful integration is about using the right tools (in the toolbox) for the right task. Now we have a whole new drawer in our toolbox full of Azure goodies & widgets. This functionality is just too compelling to be ignored….

…and now that it’s on Australian soil I’d be thinking that just about every Data center service provider should be giving you cloud functionality.

Some quick cloud advantages:

  • scale, provisioning and ease of use
    • Imagine being able to spin up a SharePoint site in the time it takes me to write this article.
      image
    • Imagine being able to ask for an extra load balanced highly available Server/Service at the click of a button. Importantly – Imagine being able to give it back again at the end of the weekend/day/next hour.
      image
  • Not wait the typical 12 weeks for a new server to be provisioned, oh and dont mention filling out the right forms. Running an application on those machines and getting a firewall port opened….that’ll be another 2 weeks…and on it goes.
  • The much beloved Enlightenment for many companies of achieving Single Sign-On – Imagine your customers being able to sign into your applications using their own Ids, Live Ids, + a bunch of other Ids without you needing to provision more services. You can house your identity accounts in Azure, locally or elsewhere – finally you don’t need a Quantum Analyst to setup Single Sign-on.
  • My experiences in the last few weeks on client sites have been back in the world of old – classic encumbered infrastructure service providers wanting to claim everything, put the brakes on any new ideas and have meetings around such concepts of adding an extra 10gb disk space to existing servers. These guys should be ‘can do’ people – it’s all about choosing the right tool for the job.
  • Microsoft have done a great job on the developer tooling front from the classic MS toolset through to Apple, PHP, Ruby, Phython etc. all being able to access, develop on, publish and deploy.
  • We could even give a bunch of HDD drives to Olaf (our gun cyclist @ Breeze) to ride to the Azure Data Center and offload our data, while we wait for the NBN to never come to our area.
  • There are some great options on the horizon coming down the track.

So let’s say we’re keen to explore – how hard/easy is it to get ‘my’ own environment & what does this mean.

The short answer is you get an Azure Footprint which could be running in a ‘Data Center’ in Sydney. Depending on what you’re playing with you could get:

- SQL Databases, Cloud Services, Scalable Mobile Device Services, Load balanced Websites/Services/Restful endpoints…and the list of ‘widgets’ goes on and on.

How do I interact with this environment:

Often the issue around alot of this is that because my beloved ‘servers’ are running somewhere else I’m concerned over how much control we get.

We enter into the Hybrid Integration space – where as you can imagine not *everything* is suited for the Cloud, there will be things you keep exactly as they are. So there will be many many scenarios where – we have something running locally as well as something running in Azure. Some options we have available are to make our servers ‘feel at home’:

  • VPN connection – we can have several flavours of a VPN connection that connect our Azure Footprint to our local network. for e.g. local network is 10.10.x.x/16, Azure network 10.50.x.x/16. Full access to all the machines/services and other things you have running. CRON jobs, FTP, scripts, processes, linux boxes, samba shares, etc etc.. (I do realise the integration world is never as easy as we see it in the magazines)
  • RDP Connections – standard level of service really from any Service provider.
  • Remote PowerShell Access
  • Azure Service Bus - Applications Level Web/WCF/Restful Services connectivity. An Application Service can run either locally or in the cloud and this feature allows your Service to be accessed through a consistent Endpoint within the cloud, but the calls are Relayed down to your Application Service. There’s a few different ways we can ‘relay’ but the public endpoint could house all the clients & their device requests, while your existing application infrastructure remains unchanged.
  • SQL Azure Data Sync – sync data between clouds & local from your databases. So for many clients, come 8pm each day, their local database has all the Orders for the day as per normal, without the usual provisioning headaches as the business responds to new market opportunities to support smart devices.
  • We even get pretty graphs….
    image
    • But wait there’s more…..
    • These details are typical performance monitor counters + diagnostic information. We can use Azure Admin tools to import these regularly and import them into our typical tools.
    • System Center does exactly this – so our ‘dashboard’ of machines will list our local machines as well as our cloud machines. Your IT guys have visibility into what’s going on.

We’ve been using Singapore DCs or West Coast US with pretty good performance times across the infrastructure. 

What does having a local Windows Azure Data Center mean to me:

  • Medical Industry – we have several medical clients allowing us to innovate around Cloud technologies using HL7 transports. Faster time to market and higher degrees of re-use.
  • Cloud Lab Manager – www.cloudlabmanager.com can run locally for all training providers. Breeze has created an award winning cloud based application that will certainly benefit from this piece of great news.
  • Creating a cloud based application is now feasible (this particular one was due to the sensitive nature of information it carried)
  • And lastly I can house my MineCraft server – well it’s my 10 yr old sons and half the school I reckon.

 

So for you…

Ask yourself the question – are you getting all these features from where you currently host/run your hardware?

Lack of infrastructure and provisioning challenges shouldn’t be holding back new ideas & business movement. iPads, smartphones, anywhere, any time access should be the norm, not like we’re putting another person on the moon.

It’s all about using the right tool for the job

Enjoy folks as it’s certainly exciting times for us Aussies ahead!!

Microsoft’s Announcement

Monday, May 20, 2013 12:23:00 PM (AUS Eastern Standard Time, UTC+10:00)  #    Comments [0] -
Azure | Integration | ServiceBus | BizTalk | SharePoint | Dev | Events | General | Tips | Training | Win2012
# Tuesday, October 12, 2010

Today I decided to crack open the BTS 2010 SharePoint WS Adapter to see if it takes advantage of the great new interfaces exposed by SharePoint 2010, specifically Microsoft.SharePoint.Client.dll and Microsoft.SharePoint.Client.Runtime.dll.

At a glance, the benefits of this new Client APIs are:

  1. Runs on a non SharePoint installed box.
  2. Lightweight and flexible – only get back what you ask for. As opposed to the classic SP Server API that populates the SPWeb collection (for e.g.) only if you just want the title field and not 10MBs worth of other data.
  3. Batch approach – load up several commands and batch them over the wire when needed.
  4. Supports both read/write from the client back to SP Server.
  5. Uses XML and JSON over the wire – small and fast.
  6. We can’t do *everything* we can on the Server Side – e.g. Service Application management, i.e. kicking off a search index crawl.

A little piccy of what’s going on:

image

Some classic piece of code to achieve document library reading:

1 static void Main(string[] args) 2 { 3 ClientContext ctx = new ClientContext("http://intranet"); 4 Web web = ctx.Web; 5 List docs = web.Lists.GetByTitle("Shared Documents"); 6 ListItemCollection items = docs.GetItems(CamlQuery.CreateAllItemsQuery()); 7 ctx.Load<Web>(web); 8 ctx.Load(docs); 9 ctx.Load(items); 10 ctx.ExecuteQuery(); 11 Console.WriteLine("The list has {0} items.", docs.ItemCount); 12 foreach (ListItem item in items) 13 { 14 Console.WriteLine("Item:{0}", item["Title"]); 15 } 16 //delete an item. 17 //items[1].Update(); 18 //items[1].DeleteObject(); 19 //ctx.Load(items); 20 //ctx.ExecuteQuery(); 21 Console.ReadLine(); 22 }

Note: Line 10 is where all the magic happens – if you imagine, we load up the client OM classes and the props etc. are all ‘blank’ until we do an ExecuteQuery() which then populates what we ask for.

The above sample is pretty simple showing how to connect to a document library on a ‘remote’ server (security allowing – I didn’t add a ctx.Credentials=… line in the above, but all possible).

So let’s move on a crack open the BTS 2010 SharePoint WS Adapter…

Just before we go there I’d like to point out that the Microsoft.SharePoint.dll (aka Server API) has the ability to connect to remote servers, although the code needs to be executed on a machine that has a local SharePoint install.

e.g.

SPSite site = new SPSite(“http://remoteserver.acme.com”);

SPWeb web = site.OpenWeb();

What I am trying to avoid with the BTS SharePoint adapter is the need to have the ‘BTS Web Service’ component installed on remote Farms. Just complicates the issue far too much with the SharePoint admins.

The BTS 2010 Story

I setup and installed the BTS SharePoint WS Adapter through the Configuration.exe tool successfully.

Essentially this tools runs a ‘web site check’ to make sure SharePoint is successfully setup and installed.

image

To make this happen, the configuration tool runs either:

  1. Microsoft.BizTalk.KwTpm.StsOmInterop3.exe – for WSSv3
  2. Microsoft.BizTalk.KwTpm.StsOmInterop4.exe – for WSSv4

to determine the site as follows:

image

Note: The URL and note the URL in the BTS Configuration above. Here I’ve already configured the adapter and I’m just showing the commands that the configurator runs behind the scenes.

Once configuration is complete you will see a new virtual directory added  to your selected site e.g. http://intranet.

As shown in IIS Manager.

image

Depending on the SharePoint version this virtual directory will map to:

  1. C:\Program Files (x86)\Microsoft BizTalk Server 2010\Business Activity Services\BTSharePointV4AdapterWS
    or
  2. C:\Program Files (x86)\Microsoft BizTalk Server 2010\Business Activity Services\BTSharePointV3AdapterWS (previous bts2009 adapter)

A Basic BTS/SharePoint picture

Essentially the BTS SharePoint Adapter consists of 2 parts:

  1. A BTS Adapter that talks to the BTS SharePoint WS. This is a ‘classic’ adapter and does not talk the newer WCF framework (which does have advantages and disadvantages)
  2. A BTS SharePoint WS – this does all the work against the SharePoint library and talks local SharePoint APIs.

image

 

Let’s look closer at the BTSharePointV4AdapterWS folder

image

- this folder, or addition needs to be available locally to whichever SharePoint site you are calling through the OOTB BTS SharePoint adapter, even though the SharePoint APIs support remote Servers.

- the bin folder has the Microsoft.BizTalk.KwTpm.WssV4Adapter.WebService.dll which is 78kb.

I wanted to find out whether this DLL used the new SharePoint Client APIs when meant having a peek at the ‘references’ of this DLL in IL.

Dissassembling Microsoft.BizTalk.KwTpm.WssV4Adapter.WebService.dll

Using .NET Reflector I was able to get this picture…

image

NOTE: on this list there is Microsoft.SharePoint, but not Microsoft.SharePoint.Client.dll
(this is not looking good…could be late bound, but… I doubt it)

Digging into the actual WssAdapter class we get the following of note:

image

The GetDocuments(string, string, string, Int32, DocExtOfficeIntegration)… is a key method.

The APIs show that the 1st parameter is a siteUrl (and following the implementation code through) which has the potential to point to another SharePoint server to make the connection (in the RequestInfo class if you’re going to dig yourself :))
Note: the PREVIOUS version, BTS2009 has the same Interface/Method signature and it requires the BTS SharePoint Adapter WS to be deployed on the remote SharePoint Server, even though the signature looks as though it will support the remote server.

So in conclusion the BTS SharePoint Adapter WebService has:

  1. NOT got any newer SharePoint Client API code within in.
  2. The ability to contact a remote server through the WebService APIs.
  3. But depends on whether the BTS Adapter will pass the ‘remote’ URL to the ‘local’ WS, or will the Adapter try to contact the remote SharePoint Server directly looking for a WS there???

I’m thinking it’s the latter…

A little more to unravel the SharePoint mystery…

Tuesday, October 12, 2010 1:08:00 PM (AUS Eastern Standard Time, UTC+10:00)  #    Comments [0] -
BizTalk | 2010 | Insights | SharePoint | SharePoint | 2010
# Tuesday, November 03, 2009

As far as I know there’s some good news and bad news…

Good news: the existing BizTalk SharePoint Adapter *should* work with SharePoint 2010 – you will however need to add ‘<rebinding>’ section to the existing adapters web.config *if* the SharePoint 2010 is installed locally to the BizTalk Server.

The ‘rebinding’ tells your local .NET app that even though you want V12.0.0.0 of the SharePoint APIs, V14.0.0.0 assemblies will give it to you.

Bad News: there’s no new BTS Adapter on the Horizon for this – AFAIK.

------

With SharePoint 2010 we now have the capability to involve many tighter technologies such as:

1) event notification, rather than polling for the adapter.

2) LINQ and ADO.NET Entities to query the Data.

3) SharePoint Client WCF Service – Client.svc . This is a lightweight and fast interface, where we can batch up requests, send them over the wire and get back just what we ask for.

4) Lists.ASMX web service (+ the others) for backward compatibility.

When I get some time…:D, I’m keen to develop a .NET LOB WCF Adapter.

Tuesday, November 03, 2009 12:05:01 AM (AUS Eastern Daylight Time, UTC+11:00)  #    Comments [0] -
2009 | BizTalk Adapter Pack | Insights | SharePoint | 2010
# Monday, November 02, 2009

Well – after spending *far* too long trying to get a little Red X to disappear from my BTS Configuration tool, so I can have a green light to configure the SharePoint adapter, I thought “There’s got to be an easier way”

image
Exhibit A – your honour. The SharePoint Adapter Configured.

So – what I did was roll my sleeves up and do this by hand.

This particular install – BTS09 x86, I installed WSS V3.0 with Sp2 and created a local sharepoint web application, site collection and had a whole bunch of SharePoint happiness coming back to me on http://biztalk (my server name).

All good I thought – except the configuration tool didn’t like what it found. I looked at logs, ran network sniffers and even manually ran the tool  Microsoft.BizTalk.KwTpm.StsOmInterop3.exe http://biztalk with success:

image

But still no joy in the configurator.

Here’s how to do it manually:

  1. Setup your local or domain SharePoint Groups
    Typically this is the ‘SharePoint Enabled Hosts’ Group – if it already exists on the domain, then great, if not create it. For this I created my group on the local machine.
    I also added as members, my biztalk service account and my Sharepoint Service Account.
  2. Configure IIS – BTS SharePoint WS Web Application
    1. Within the BizTalk Installed folders – e.g. c:\program files\Microsoft BizTalk 2009\Business Activity Services, you’ll find the set of WebServices to choose from. Select the right one for your SharePoint deployment.
    2. image
    3. As you can see I selected BTSharePointV3AdapterWS (for WSS V2 SP3, select BTSharePointAdapterWS).
    4. This is the folder you will point IIS to later.
    5. Open this folder and you’ll see a web application with a web.config.tmpl
    6. Copy the web.config.tmpl and rename the *copy* to web.config
    7. Open up your Web.Config in Notepad and configure as follows:

        <?xml version="1.0" encoding="utf-8"?>
        <configuration>
          <system.web>
                <httpModules>
                    <!--add name="UrlAuthorization" type="System.Web.Security.UrlAuthorizationModule" /-->
                </httpModules>

            <!-- Change debug="true" if you want to debug this web service -->
            <compilation defaultLanguage="c#" debug="false" />
            <customErrors mode="Off" />
            <!-- Windows Authentication is required for this web service. -->
            <authentication mode="Windows" />
            <!-- Impersonation is required for this web service. -->
            <identity impersonate="true" />
            <authorization>
                <allow roles="SharePoint Enabled Hosts" verbs="GET,HEAD,POST"/>
                <deny users="*"/>
            </authorization>

            <!-- Uncomment this block if you want to do some tracing of this web service -->
            <!-- <trace enabled="true" requestLimit="10" pageOutput="false" traceMode="SortByTime" localOnly="true" />  -->
            <globalization requestEncoding="utf-8" responseEncoding="utf-8" />

            <!-- The size of a document being posted to SharePoint depends on this setting -->
            <httpRuntime maxRequestLength="100000" />
            <trust level="Full" originUrl="" />
          </system.web>
          <runtime>
            <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
              <dependentAssembly>
                <assemblyIdentity name="Microsoft.SharePoint" publicKeyToken="71e9bce111e9429c"/>
                <bindingRedirect oldVersion="11.0.0.0" newVersion="12.0.0.0"/>
              </dependentAssembly>
            </assemblyBinding>
          </runtime>
        </configuration>

      1. (you can always go back and tighten security up on this when you’ve got it working).
      2. Note the ‘SharePoint Enabled Hosts’ – local group here.
      3. I’ve also removed the ‘Documentation’ tags so I could get some WSDL to make sure it works within the browser.
      4. Save your web.config within Notepad.
      5. NOTE: make note of the Folder Path to get here as we’ll need it in IIS next.
    8. Configuring IIS
      1. Bring up IIS Admin MMC snapin.
      2. Select your SharePoint enabled Web Site, I selected ‘Default Web Site’. Right click when ‘Default Web Site’ is Selected and select ‘Add Application’
        image
        note: IIS 7.0 Manager shown.
      3. Configure this as follows:
        image
        (Note – the App Pool User should be able to post into BizTalk and SharePoint)
        Physical Path: <path you had previously to either V2 or V3 of your BTSharePointV3Adapter…>
      4. Click OK.
      5. To Test your WS: browse to: http://<your server>/BTSharePointAdapterWS/BTSharePointAdapterWS.asmx
      6. You *should* get this:
        image
        You can invoke the IsAlive function and get TRUE back.
      7. If not, then fix your IIS related errors, at this point you’ve got a WS that uses the SharePoint APIs (locally). Some things to check:
        1. Local file security – make sure the Web App Pool acct can access those directories.
        2. Windows Auth is turned on, on your Web App.
        3. Check IIS log files for clues.
      8. You’re done on the IIS side of things, let’s configure BTS Side.
  3. Configuring BizTalk Side
    Fortunately the WSS Adapter is installed as part of the BizTalk Runtime configuration – it’s just not configured. So as far as registering the adapter with BizTalk it’s already been partly done.
    1. Install the “I’ve been Configured Registry Keys” – I took these from a previously successful 2009 install.
    2. Once the registry keys have been applied you’ll need to go and configure the …\TPM key to reflect your setup as follows:
      1. In Particular – configure your SharePoint SiteID to the one you saw in IIS.
      2. image
  4. How is this Different for a x64 bit Install
    1. The IIS piece is the same.
    2. The BTS Piece – the Perf counters are the same,
      but the ..\TPM piece is under HKLM\SOFTWARE\WOW6432Node\Microsoft\BizTalk Server\3.0\ConfigFramework
    3. So you’ll need to ammend 1 of the above 2 REG files.

You’re done!

Why oh why is this so hard from within the Configurator.

NOTE: There *USED* to be a Registry key that told the BTS WSS Adapter where to go looking for the BTSharePoint WS – a URL (..STSServiceUrl). This eliminated the need for a local machine install of SharePoint/WSS. Alas…this is *NOT* the case with WSS Adapter post BTS06.


Monday, November 02, 2009 9:02:11 PM (AUS Eastern Daylight Time, UTC+11:00)  #    Comments [0] -
BizTalk | 2009 | SharePoint | MOSS | 2010
Archive
<December 2014>
SunMonTueWedThuFriSat
30123456
78910111213
14151617181920
21222324252627
28293031123
45678910
Blogroll
 AppFabric CAT
AppFabric Windows Server Customer Advisory Team - New Blog.
[Feed] BizTalk 2006 - Windows SharePoint Services adapter
BizTalk 2006 Sharepoint adapter!!
 Breeze SharePoint 2010 Bootcamp
Breeze SharePoint 2010 Bootcamp
[Feed] BTS 2006 R2/EDI
[Feed] Chris Vidotto (MS BTS Legend)
Needs no intro....
 Mark Daunt
BTS/SPS/.NET GURU!!!
About the author/Disclaimer

Disclaimer
The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.

© Copyright 2014
Breeze
Sign In
Statistics
Total Posts: 607
This Year: 11
This Month: 1
This Week: 0
Comments: 270
All Content © 2014, Breeze