Purge without Archiving

One option for managing the growth in data is to store the BAM data for a certain period of time, after which it should be purged.  This is achieved by defining a time period for which an activity's BAM data should be kept, and by instructing BAM to not backup the data after the time period expires.

• To define the time period for keeping the data, you would set the TimeLength and TimeUnit attributes on a BAM activity, using the set-activitywindow command.  The command bm.exe set-activitywindow -Activity:PurchaseOrder -TimeLength:1 -TimeUnit:Month would ensure that BAM data for the PurchaseOrder Activity is kept for one month before being archived or purged.
• By doing the above and the using the set-archive command to instruct BAM not to archive the data (bm.exe set-archive -Activity:PurchaseOrder -ShouldArchive:False) the BAM infrastructure will ensure that any data older than the provided time window will be purged.

(Reference of BAM Activity management commands: https://msdn.microsoft.com/en-us/library/bb246031.aspx)

Archiving without Purge

The second option is to maintain the time window, as with the first option, and to enable archiving (bm.exe set-archive -Activity:PurchaseOrder -ShouldArchive:True).  This will instruct the BAM infrastructure to move any data older than the provided time window into the BAMArchive database before removing the data from the BAMPrimaryImport database tables.  Within the BAMArchive database, one table per day per Activity will be created to store the archived data.

This is a great way to ensure that the size of the BAMPrimaryImport tables are kept under control, but there are two issues that need to be kept in mind with this approach:

1. Once the data is moved to the BAMArchive database, the BAM Views will no longer reference this data, so queries on archived data will need to be constructed manually.
2. There is no automatic process for removing data from the BAMArchive database, so over time the number of tables in the BAMArchive database will increase and the disk space utilised by this database will continue to grow.

Having this archived data available when you want to do some historical analysis on the data is very useful, but there is a tipping point where the amount of space the data utilises outweighs the benefits of keeping the data on hand.  It is at this point that an automated mechanism for cleaning up the BAMArchive database becomes required. 

BAM Archive cleanup Script

To this end, the below script is a script that I have utilised to automate this process.  The script queries the sys.objects container for any user tables that start with the text "bam_", and which have been modified more than 45 days ago.  It then uses a cursor to iterate over the result, and drops each table in turn.

NOTE: As this script is not restricted to a particular database, it will drop any tables in any database, where the table meets the defined criteria.  Please review the script carefully before implementing. 

For this purpose, the execution statement to actually drop the table has been commented out.  Once you are happy that the logic is safe, you can uncomment this line, implement the stored procedure and then schedule its execution from a SQL Agent job.

CREATE PROCEDURE [dbo].[usp_CleanUpBAMArchiveTables]
AS
BEGIN
 DECLARE @tname VARCHAR(100)
 DECLARE @sql VARCHAR(max)
  
 DECLARE db_cursor CURSOR FOR 
 SELECT name AS tname
 FROM sys.objects
 WHERE 
 modify_date < GETDATE() - 45
 AND name LIKE 'bam_%'
 AND type='U'
  
 OPEN db_cursor 
 FETCH NEXT FROM db_cursor INTO @tname 
  
 WHILE @@FETCH_STATUS = 0 
 BEGIN 
 SET @sql = 'DROP TABLE [' + @tname + ']'
 --EXEC (@sql)
 PRINT @sql
  
 FETCH NEXT FROM db_cursor INTO @tname 
 END 
  
 CLOSE db_cursor 
 DEALLOCATE db_cursor
END

Standard Approaches to Validation

The default XMLReceive pipeline uses the standard XML Disassembler component to identify the deployed schema against which the message should be validated and, optionally, will validate the received XML message against this identified schema.  When configuring this validation you will need to set the “ValidateDocument” property to True, and provide the fully qualified assembly names for the schemas you want to validate.

Once configured in this way the incoming messages are matched against the schemas in the DocumentSpecNames property, and then validated against the schema.  As soon as a validation error is encountered, the XML Validator throws an exception with the inner exception containing the reason for the validation failure.  The resulting error would look something like this, indicating that the MonthNumber element probably has alphanumeric text as content, but the MonthNumber element is defined as xs:int:

There was a failure executing the receive pipeline: "Microsoft.BizTalk.DefaultPipelines.XMLReceive, Microsoft.BizTalk.DefaultPipelines, Version=3.0.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" Source: "Pipeline " Receive Port: "Test Services" URI: "/TestServices/Test.svc" Reason: The document failed to validate because of the following error:"The 'https://test.org/schemas/1.3.0:MonthNumber' element has an invalid value according to its data type." .

The downside of implementing this method of validation is that you have to essentially hard-code the schema names in the configuration for the pipeline.

The second approach is to create a custom pipeline, composed of the standard XML Disassembler and standard XML Validator components.  This essentially moves the validation logic from the XML Disassembler to the XML Validator component.  A major benefit of using this approach is that you do not need to specify the document schema to validate the message against … the pipeline component will use the message's target namespace and root element name information to find the appropriate schema.  The result is that the pipeline will dynamically be able to identify the schema for the received message, and then dynamically validated the message against the identified schema, making the pipeline a generic pipeline that can be used to validate any incoming message.  As with the first approach, however, this approach will also only raise the first validation error.

Before discussing how we can identify multiple validation errors, let’s discuss how we can return error information for an invalid message to the sender of the message.

Dealing with Invalid Messages

When an incoming message fails validation it can be regarded as a “poison message”  (https://winterdom.com/2007/02/poisonmessagesandorderedprocessing), and should not be allowed to process further through the solution.  Instead, details of why the message failed validation should be returned to the sender so that they can make the necessary changes in their solution to correct the cause of the failure. 

Using the WCF-WSHttp and WCF-BasicHttp adapters achieving this is rather easy. By checking the “Include exception detail in faults” flag in the “Messages” tab for the WCF settings, BizTalk will return the exception from the pipeline to the WCF-WSHttp or WCF-BasicHttp adapter, which will then return the exception as a SOAP fault to the sender.

The result will be that when the sender application submits the message to a BizTalk web service, the application would not receive the HTTP 200 acknowledgement until the message has validated successfully.  Where the message fails validation, the sender will receive the validation error as part of a SOAP Fault, returned with an HTTP 500 error.

The sender system would then need to correct the message and resubmit the message to the BizTalk web service.  If the message fails validation a number of times, the process of sending, receiving a single error, and resubmitting the message will be a very time-consuming and frustrating process. 

(Of course, the best would be for the sender to be validating the message against the schema BEFORE they send it, but I have seen it happen far too often where this is not done.)

Solution

The ideal solution to this would be to have the validation process identify as many failures as possible and return a message to the sender with the detail for all the failures.

Saravana Kumar developed a pipeline component that addresses this requirement on the basis that all the validation errors are identified and then used to formulate a new message.  This new message is then returned as a standardised Error XML message to the sender (https://blogs.digitaldeposit.net/saravana/post/2008/04/05/Extended-XmlValidation-Pipeline-Component.aspx).

While this component performs the core functionality of identifying all the validation errors, I wanted something a little more direct.  Imagine a scenario where you have an event-based message exchange hub, using one-way WCF-WSHttp receive locations for receiving messages of varying structural complexity from partners via SOAP-based communication.  A key principle of this architecture would be that the sender of a message should receive a communication acknowledgement (HTTP 200) ONLY if the message has been validated successfully.  Therefore, if there are any errors encountered BEFORE the message has been received by the BizTalk Message Box, these errors are to be returned to the sender as a SOAP fault, rather than as a new message.  This would result in the sender receiving an HTTP 200 acknowledgement if the message was successfully validated, or an HTTP 500 error, and the SOAP fault with all validation errors, if the validation failed.

Based on these requirements I developed a new custom XML Validator pipeline component.  This component also needed a configurable maximum error limit, so that the validation process would halt if a specified number of errors in the validation process were encountered.  In a custom receive pipeline the standard XML Disassembler component will still be used to identify the appropriate message schema, but then this custom XML Validator component will then validate the message against the message’s schema, gather all the validation errors (up to the maximum error count), and raise a new exception with detail for each validation error included.  This exception would then be returned to the sender of the message in the same way as described earlier in this blog. 

The result is that when a message submitted fails validation, the validation errors are returned to the sender as a SOAP fault, as shown below:

<s:Envelope xmlns:s="https://www.w3.org/2003/05/soap-envelope" xmlns:a="https://www.w3.org/2005/08/addressing">
   <s:Header>
      <a:Action s:mustUnderstand="1">https://schemas.microsoft.com/net/2005/12/windowscommunicationfoundation/dispatcher/fault</a:Action>
   </s:Header>
   <s:Body>
      <s:Fault>
         <s:Code>
            <s:Value>s:Receiver</s:Value>
            <s:Subcode>
               <s:Value xmlns:a="https://schemas.microsoft.com/net/2005/12/windowscommunicationfoundation/dispatcher">a:InternalServiceFault</s:Value>
            </s:Subcode>
         </s:Code>
         <s:Reason>
            <s:Text xml:lang="en-ZA">There was a failure executing the receive pipeline: "BizTalk.Common.Pipelines.XMLValidatingReceive, BizTalk.Common.Pipelines, Version=1.0.0.0, Culture=neutral, PublicKeyToken=0ba159bca7ecb7f3" Source: "CustomXMLValidator Component" Receive Port: "Test Services" URI: "/TestServices/Test.svc" Reason: XML validation failed for a "https://ijs.gov.za/schemas/sajsvc/messages/DocketReadyNotification/3.0#DocketReadyNotification" message, with a message ID of "0d723957-861b-4896-9b3d-9985daa16fe2". Error Message(s): 
Line: 28, Position: 38, Error: The 'https://test.org/schemas/1.3.0:MonthNumber' element has an invalid value according to its data type.
Line: 29, Position: 37, Error: The 'https://test.org/schemas/1.3.0:YearNumber' element has an invalid value according to its data type.
Line: 40, Position: 13, Error: The element 'DocumentCategoryID' in namespace 'https://test.org/schemas/1.3.0' has incomplete content. List of possible elements expected: 'https://test.org/schemas/1.3.0:ID'.
Line: 67, Position: 12, Error: The element 'CaseCharge' in namespace 'https://test.org/schemas/3.0' has incomplete content. List of possible elements expected: 'https://test.org/schemas/1.3.0:ChargeStatute'.</s:Text>
         </s:Reason>
         <s:Detail>
            <ExceptionDetail xmlns="https://schemas.datacontract.org/2004/07/System.ServiceModel" xmlns:i="https://www.w3.org/2001/XMLSchema-instance">
               <HelpLink i:nil="true"/>
               <InnerException i:nil="true"/>
               <Message>There was a failure executing the receive pipeline: "BizTalk.Common.Pipelines.XMLValidatingReceive, BizTalk.Common.Pipelines, Version=1.0.0.0, Culture=neutral, PublicKeyToken=0ba159bca7ecb7f3" Source: "CustomXMLValidator Component" Receive Port: "Test Services" URI: "/TestServices/Test.svc" Reason: XML validation failed for a "https://ijs.gov.za/schemas/sajsvc/messages/DocketReadyNotification/3.0#DocketReadyNotification" message, with a message ID of "0d723957-861b-4896-9b3d-9985daa16fe2". Error Message(s): 
Line: 28, Position: 38, Error: The 'https://test.org/schemas/1.3.0:MonthNumber' element has an invalid value according to its data type.
Line: 29, Position: 37, Error: The 'https://test.org/schemas/1.3.0:YearNumber' element has an invalid value according to its data type.
Line: 40, Position: 13, Error: The element 'DocumentCategoryID' in namespace 'https://test.org/schemas/1.3.0' has incomplete content. List of possible elements expected: 'https://test.org/schemas/1.3.0:ID'.
Line: 67, Position: 12, Error: The element 'CaseCharge' in namespace 'https://test.org/schemas/3.0' has incomplete content. List of possible elements expected: 'https://test.org/schemas/1.3.0:ChargeStatute'.</Message>
               <StackTrace>at Microsoft.BizTalk.Adapter.Wcf.Runtime.BizTalkServiceInstance.EndOperation(IAsyncResult result)
   at AsyncInvokeEndEndTwoWayMethod(Object , Object[] , IAsyncResult )
   at System.ServiceModel.Dispatcher.AsyncMethodInvoker.InvokeEnd(Object instance, Object[]&amp; outputs, IAsyncResult result)
   at System.ServiceModel.Dispatcher.DispatchOperationRuntime.InvokeEnd(MessageRpc&amp; rpc)
   at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage7(MessageRpc&amp; rpc)
   at System.ServiceModel.Dispatcher.MessageRpc.Process(Boolean isOperationContextSet)</StackTrace>
               <Type>Microsoft.BizTalk.Message.Interop.BTSException</Type>
            </ExceptionDetail>
         </s:Detail>
      </s:Fault>
   </s:Body>
</s:Envelope>

Formatting of this SOAP fault will be a challenge for another day … anyone have ideas on this?

The source code for this CustomXMLValidator component is available from my SkyDrive, correction my OneDrive.

Check them out at the following URLs:

· BizTalk Server 2009 Scale-out Configurations Poster

· BizTalk Server 2009 Database Infrastructure Poster

· BizTalk Server 2009 BAM Poster

For those who are not aware of these two technologies, the detail below should provide good context:

BizTalk Server 2009

With the public beta release of BizTalk Server 2009, Microsoft is delivering the first customer preview of the multi-release road map announced in September 2008 and is giving customers the first look of the feature-complete download. BizTalk Server 2009 supports the latest Microsoft application platform technologies, including Windows Server 2008, Microsoft Visual Studio 2008 SP1, Microsoft SQL Server 2008 and the .NET Framework 3.5 SP1. BizTalk Server 2009 also delivers expanded new connectivity options including new integration with Oracle Corp.’s E-Business Suite, as well as updated platform support for the most recent versions of IBM Corp.’s Customer Information Control System (CICS), Information Management System (IMS), DB2, DB2/400, DB2 Universal Database and WebSphere MQ.

BizTalk Server 2009 also delivers improved scalability and reliability through support for SQL Server 2008, Windows Server 2008 Hyper-V virtualization and enhanced failover clustering. It provides significant new enhancements to both individual and team productivity by enabling new interoperability with Microsoft’s application life-cycle management (ALM) solution Visual Studio Team System and Team Foundation Server. This allows development teams to utilize the integrated source control, bug tracking, team development support, Project Server integration, and support for automating builds via MSBuild for a more seamless development and testing experience.

BizTalk RFID Mobile also extends the power of BizTalk Server RFID to mobile devices running Windows Mobile and Windows CE. In addition, BizTalk RFID Mobile delivers simple device management and offline processing capabilities, all of which help reduce the total cost of ownership.

ESB Guidance 2.0 CTP

The first public CTP release of the Microsoft ESB Guidance 2.0 for Microsoft BizTalk Server 2009 incorporates many new and expanded features include the following:

• New samples:
• SSO Configuration provider for Enterprise Library 4.0
• Multiple Web Service Execution Sample
• Exception Handling Service Sample
• New ESB Web services:
• Generic Itinerary Services ( no itinerary header required)
• New core features:
• Alignment with Microsoft BizTalk Server 2009 ( Beta )
• ESB Configuration tool
• Centralized itinerary store
• Itinerary resolver components
• Itinerary forwarder pipeline component
• Itinerary selector pipeline component
• Itinerary designer
• Centralized configuration uses Enterprise Library 4.0 Configuration Block
• Centralized caching uses Enterprise Library 4.0 Caching Block
• Multiple service invocation using both messaging and orchestrations
• Itinerary BAM tracking
• Improved ESB Core engine and itinerary execution

For those who focus on BizTalk, and who may be feeling that “Dublin” is encroaching on BizTalk’s territory, make sure you read the section titled “Dublin” and BizTalk Server.  Although it only touches on this topic briefly it is a great synopsis of the different objectives of the two technologies.

Well, I have finally gotten round to posting the solution to the South African BizTalk User Group forum at EATS - Scenario 1 Solution Pack.  Download it and compare it to your solution, or download it to see one possible solution as to how the challenges presented in the scenario could be solved.

As always, any comments / suggestions / criticisms are most welcome.

BTW: Look out for the second scenario, which will be posted soon.  As can be expected, each subsequent scenario will present greater degrees of difficulty and will cover greater areas of BizTalk's capabilities.

Home Improvement Retailer – Integrated Sales Order Solution.

• Charles (Sales Officer) creates a new sales order.
  • Customer data is received from SAP using BizTalk. (Using BizTalk SAP Adapter)
• Charles submits the order.
  • K2 uses BizTalk to do a credit check on an IBM server. (Using BizTalk Host Adapter for IBM DB2)
  • Based on the data received from the IBM server an approve or decline decision is made in the K2 process.
• When the credit check is approved
  • The Sales Order information is sent from K2 and captured back into SAP using BizTalk. (Using File Adapter and SAP Adapter)
  • An availability date is received back into the K2 process from SAP via BizTalk. (Using K2 Adapter)
• A message is sent back to BizTalk to update data into the BizTalk BAM. (Using BizTalk MSMQT Adapter)
• K2 creates a calendar entry in MOSS based on the availability date.
• K2 sends an Office Communications Server message and email to the Sales Team to indicate the sale has been processed.
• An email is sent to the customer indicating the sale has been processed.

Although the K2 guys will be using stubs to simulate SAP and DB2 this should be a great demo!  We should get a good idea of how K2 adds value to BizTalk and how human workflow can be integrated into BizTalk's business process automation focus.

Time permitting, remember that after this demo we will do a dive into the enhancements and new features coming down the line with BizTalk Server 2009.

It's going to be a jam-packed session ... so we hope to see you there!

The basic requirement was that the customer was looking to develop a solution that would make use of the standard send port filters, outbound map resolution, and BizTalk's management console to provide a flexible solution for sending HTML email to one or more standard email addresses.  They specifically did not want to use an orchestration and a dynamic send port, as they wanted to use the send port filters as the "rule base" to determine which messages should be routed to which static email addresses, and they wanted to use the BizTalk administration console to maintain the email addresses and the filter rules (which are mainly BTS.MessageType filters).

This set of requirements presented the following challenges:

1. How do you architect the solution so that you can setup and manage a specific send port once (e.g. a send port for billing@joesrouting.com) and route different messages to this send port.  Yet, each message needs to be transformed in accordance with the message's unique type before the message is sent to the specified email address?
2. Once you understand how you are going to manage the routing and selective transformation requirements, how do you ensure that the selected transformation produces the HTML formatted email content specific to the message type you are sending?
3. The last challenge, although far easier to state, was somewhat more complex to resolve: How do you send an HTML email via a static send port?

Routing and Transforming Messages

For those who have worked with BizTalk for a while, this problem will not present too much of a challenge, as this functionality is native to BizTalk.  The send port in BizTalk follows the following process (simplified for the purposes of this post):

1. Receive the outbound message, in accordance with the send port's subscription.
2. Find any maps configured for the current send port, where the source schema in the map matches the current message's BTS.MessageType context property.
3. Execute the map, if a match is found.  If no match is found the message is passed on to step 4.
4. Call the configured pipeline, passing in the output of the map.
5. Execute the pipeline.
6. Pass the output of the pipeline to the configured adapter.
7. The adapter then performs its logic on the finalised message.

Through this process the send port is able to receive any message type, and for each message type that is received a different map may be executed before the message is processed further.  This process therefore fulfills the first "challenge" in this scenario, as we will.

Producing HTML Output

Using this approach to route and transform messages, the next challenge is how to produce HTML from a map.  Once again, BizTalk provides a simple solution to achieve this: a BizTalk map can be configured to use an XSLT file, by choosing the XSLT file from the "Custom XSL Path" property in the map's properties.  The XSLT that you use can then produce HTML and it can use content from the source schema to produce an HTML formatted output containing data from the input message.  An example of such an XSLT file is shown below:

<xsl:stylesheet version="1.0" xmlns:xsl="https://www.w3.org/1999/XSL/Transform">
    <xsl:output omit-xml-declaration="yes" method="xml" standalone="yes" version="1.0" encoding="UTF-8" />
    <xsl:template match="/">
        <html>
            <head>
                <title>Billing Enquiry: Corporate</title> 
            </head>
            <body> 
                    <p>
                        The details below relate to a billing enquiry receive at <xsl:value-of select="//Header/QueryTime" /> on <xsl:value-of select="//Header/QueryDate" />.
                    </p>
                    <table style="border:none;padding: 0px;width:100%;">
                        <tr>
                            <td>Contact Person:</td>
                            <td>
                                <xsl:value-of select="//Query/ContactName" />
                            </td>
                        </tr>
                        <tr>
                            <td>Contact Number:</td>
                            <td>
                                <xsl:value-of select="//Query/ContactNo" />
                            </td>
                        </tr>
                        <tr>
                            <td>Account Number:</td>
                            <td>
                                <xsl:value-of select="//Query/AccNo" />
                            </td>
                        </tr>
                        <tr>
                            <td>Query:</td>
                            <td>
                                <xsl:value-of select="//Query/Description" />
                            </td>
                        </tr>
                    </table> 
            </body>
        </html>
    </xsl:template>
</xsl:stylesheet>

A particular snag that caught me during the implementation of this XSLT within the map is that BizTalk Mapper kept adding a META tag into the produced HTML, and it would change the nature of some of the tags, e.g. if we had a tag that was "<br/>" in the XSLT file, it would come out as "<br>" once the map had been executed.  It was only after I realised that I had forgotten the output control declaration that I realised why this was happening.  The point is: make sure that you include the following line in your XSLT file to ensure the correct processing takes place:

<xsl:output omit-xml-declaration="yes" method="xml" standalone="yes" version="1.0" encoding="UTF-8" />

Sending HTML via a Static Send Port

With the routing sorted, and the maps producing HTML, the next challenge was to get the static send port to send the HTML in the body of the send port.  The challenge here is that the SMTP adapter does not natively take the content of the message and put it into the body of the email being sent via the send port.  Even if you select the "BizTalk message body part" option in the "Compose" tab of the SMTP adapter properties, the content of the message is not used as the body of the email.  Instead, the message is sent as an attachment to a blank email.  There are examples of how to ensure that a specific set of text is used as the body of the email, via a dynamic port, but there are no examples of how to do this for a static port. 

After trying many different options the result was to use a pipeline component and pipeline to set the "ContentType" property of the message being sent to "text/html".  Once this was done, the SMTP adapter was more than happy to take the content of the BizTalk message and place it within the body of the email it sent, and the email was received as an HTML-formatted email.  The code used to set this is shown in the single line below:

inmsg.BodyPart.ContentType = "text/html";

In Summary

With the challenges solved, the final result was a flexible solution that did not use an orchestration, and which used a map per message type, and a send port per email address (with each send port configured with the appropriate maps and with the pipeline that set the content type).

The first point of interest is that the announcement and Q&A provide a very clear commitment to BizTalk customers that existing investments in BizTalk will not be lost, that BizTalk will continue to grow as a product, and that upgrades will take previous investments into account.  As some customers saw "Oslo" as being a potential replacement for BizTalk Server, this should set their minds at ease.  The announcement emphasises this point by indicating that BizTalk will continue to grow as a product and will, over time, be able to interoperate with the modelling initiatives that are the embodiment of "Oslo".  So, BizTalk is here to stay!

This announcement and update also provide some more clarity around how the "Oslo" initiative is shaping up.  "Oslo" has gone from being a broadly stated idea to becoming a more and more realistic strategy and set of initiatives within Microsoft.  As with any large-scale idea, the concepts on which the idea are based go through a number of changes as the idea evolves over time and the concepts slowly formulate into more concrete definitions.   This has happened with "Oslo" as well, and this post provides some clarity around how the core of "Oslo" is focused on the concepts of model-driven development and management.  Even more interesting announcements relating to other concrete definitions that have come from the original "Oslo" idea are going to be made available at PDC in October ... so make sure you listen out for the news.

Another very interesting point is the change in name for the next release of BizTalk from the previously used name of "BizTalk Server 2006 R3" to the new name of "BizTalk Server 2009".  This is a clear indication of the number of changes and additions that have been included in this next release of BizTalk; not only is there a whole new set of platforms being used, but there are also new features being introduced, such as native support for unit testing, TFS, Hyper-V, etc.  Some might feel that this is just a marketing ploy, but I believe this change is for the best due to the number of changes that have been incorporated in BizTalk since the original BizTalk Server 2006 release, and because this naming convention is more in line with the naming convention used for products such as SQL Server and Visual Studio.  So keep a look out for CTP drops of BizTalk Server 2009 in the coming months. 

Lastly, the guys in the Connected Systems Division of Microsoft have committed themselves to making a major release of BizTalk every 2 years, with some tantalising promises of functionality that will come available through the next two releases.  The ones that pique my interest the most are the "Low-latency messaging enhancements", the hint at new BizTalk Mapper functionality, and the "Real-time business event visibility".

So, all round ... a lot to look forward to both in the short and medium term.  Interesting times lie ahead!  :-)