by community-syndication | Sep 24, 2014 | BizTalk Community Blogs via Syndication
Has anyone else seen this behaviour and better still how did you resolve it? We implemented a BAM solution using BizTalk Server 2013 and Standard SQL server 2012 that contained an aggregation. We set up a scheduled aggregation as described here. In production if we open the BAM portal and expand the Aggregations we always […]
Blog Post by: mbrimble
by community-syndication | Sep 24, 2014 | BizTalk Community Blogs via Syndication
Azure Machine Learning (http://azure.com/ml) has a number of packages already installed by default. You can see them with this following sample experiment:
R script is:
data.set <-data.frame(installed.packages());
# Select data.frame to be sent to the output Dataset port
maml.mapOutputPort("data.set");
you’ll find a little more than 400 packages.
Still you may need to use a package which is not known by Azure ML. Here is how to upload it to the environment.
NB: This post takes skmeans (k-means with a cosine distance) as an example, but this works for other packages as well.
Let’s suppose you have this code in R Studio locally.
NB: you can find information on how to setup your environment in this post. It’s in French, but bing translator is your friend.
library(skmeans)
set.seed(1234)
sample_data <- matrix(sample.int(1000, size = 20*500, replace = TRUE), nrow = 20, ncol = 500,
dimnames=list(1:20, 1:500))
fit <- skmeans(sample_data,5)
result <- data.frame(list(rownames(sample_data), fit$cluster), row.names=NULL)
colnames(result) <- c("sample data row", "cluster")
print(result)
this will give this kind of result
If you try this in Azure ML, you’ll get the following result:
Here is how to have the script loading all the necessary packages in the Azure ML environment.
So let’s now see how you construct the skmeans_packages.zip and know which lines to write here:
On the local environment (in my case Windows), I remove the R packages that are installed in My Documents\R
then in R, I install the skmeans package:
install.packages("skmeans")
this gives the following result:
So I know I have to install the following packages in order:
Then I go to the temp folder:
I Zip the zips:
and rename this new zip file as skmeans_packages.zip
I then can upload it Azure ML:
NEW, DATASET, FROM LOCAL FILE
Then you’ll be able to find it as a saved dataset in your workspace:
After it has been connected to the third dot of the Execute R Script module instance, you’ll be able to find the content in src/ folder:
so, in order to install skmeans and its two dependencies, then reference the skmeans library, you just have to enter the following lines:
install.packages("src/slam_0.1-32.zip", lib = ".", repos = NULL, verbose = TRUE)
install.packages("src/clue_0.3-48.zip", lib = ".", repos = NULL, verbose = TRUE)
install.packages("src/skmeans_0.2-6.zip", lib = ".", repos = NULL, verbose = TRUE)
library(skmeans, lib.loc=".", verbose=TRUE)
Azure ML has a pool of VM with docker-like containers (true Windows containers, named drawbridge) where the experiments run. So each time the script runs, it starts from a blank standard Azure ML environment. By bringing a zip, you add the files to that environment.
Hope this blog post will help you if you need R packages which are not in the 400+ preloaded ones in Azure Machine Learning!
Benjamin (@benjguin)
Blog Post by: Benjamin GUINEBERTIERE
by community-syndication | Sep 21, 2014 | BizTalk Community Blogs via Syndication
While working on the current upcoming installment in my BizTalk Server 2013 R2 New Features Series, I realized that I did not yet have a version of Martijn Hoogendoorn’s excellent BizTalk Server Pipeline Component Wizard that would work happily in Visual Studio 2013. As a result, I filed this issue, and then made the necessary […]
Blog Post by: Nick Hauenstein
by community-syndication | Sep 15, 2014 | BizTalk Community Blogs via Syndication
I had never come across the need to execute rules based on message metadata until a colleague of mine asked me the other day. Which is surprising as we often define routing rules based on the message context.
The basic principle is simple, – Rather than using schema based facts, we use facts based on .Net assemblies. In this case IBaseMessageContext (Microsoft.BizTalk.Message.Interop). This works well in cases where you’d like to call the rule from within a pipeline, as the context of the pipeline message (IBaseMessage) is implementing the IBaseMessageContext interface.
If, on the other hand, you want to execute the rule form an orchestration we can’t use an interface as a rule fact, as the CallRules Policy shape can’t work with interfaces. In those cases we’d need to use a custom class (the one the is used by BizTalk is internal).
Create the output fact schema
Before we create the rule you need to have your facts ready. The input fact is going to be the context object mentioned above but you need to create the output schema where you’re going to store the result if the rule evaluates to true.
Create the rule (Messaging scenario)
Open the Microsoft Business Rule Compose and create your policy and rule as you’d normally do. Then in the Fact Explorer select the .Net Classes tab, right-click the .Net Assemblies node and select Browse. The IBaseMessageContext interface is found in the Microsoft.BizTalk.Pipeline assembly. Select the assembly and expand the IBaseMessageContext in the tree view.
Drag the Read(String strName, String strNamespace) method to your rule condition:
Create the pipeline component (Messaging scenario)
If you haven’t developed a pipeline component before you can use a nuget package like Default Breeze BizTalk Pipeline Component. Simply create a class library project and install the nuget package. Follow the steps at the top of the pipeline component file before implementing the Execute method.
public IBaseMessage Execute(IPipelineContext pc, IBaseMessage inmsg)
{
//Create a policy object based on the name of the Policy
Policy policy = new Policy("MessageContextSamplePolicy");
// Create the response document
XmlDocument doc = new XmlDocument();
doc.LoadXml(@"<ns0:BreTest xmlns:ns0=""http://BreWithPromotedPropertiesSample.BreTest""><Field></Field></ns0:BreTest>");
var responseDoc = new TypedXmlDocument("BreWithPromotedPropertiesSample.BreTest", doc);
//Execute the policy and pass the message context and the response docoument
policy.Execute(new object[] { inmsg.Context, responseDoc });
var responseXml = responseDoc.Document.OuterXml;
// TODO
// Take action on the response XML...
return inmsg;
}
Create the rule (Orchestration scenario)
There are two problems to working with the context data together with orchestrations; Access the metadata and not being able to work with interfaces (CallRules Policy shape can’t work with interfaces).
Within the orchestration we don’t have the IBaseMessage from which we can easily access the context. Instead we got the XLANGMessage. The message context is not as easily accessible form the XLANGMessage as it is from the IBaseMessage. Thankfully Maxime Labelle provided insight of how this can be accomplished.
I solved these problems be creating my own class called XLANGMessageContext and from within the constructor I read through the metadata. The class also provide a Read method that will return the value for a specific property:
public class XLANGMessageContext
{
Hashtable _messageContext = null;
public XLANGMessageContext(XLANGMessage message, string name, string ns)
{
try
{
foreach (Segment segment in Service.RootService._segments)
{
IDictionary fields = Context.FindFields(typeof(XLANGMessage), segment.ExceptionContext);
foreach (DictionaryEntry field in fields)
{
XMessage msg = (field.Value as XMessage);
if (msg == null)
continue;
if (String.Compare(msg.Name, message.Name) != 0)
continue;
var key = new XmlQName(name, ns);
_messageContext= msg.GetContextProperties();
}
}
}
catch (Exception /* e */)
{
// do not provoke failure
// probably best to add some logging here
}
}
public object Read(string strName, string strNamespace)
{
var key = new XmlQName(strName, strNamespace);
var result = _messageContext[key];
return result;
}
}
Creating the rule is very similar to the messaging scenario, but instead of using the IBaseMessageContext object you’ll use the Read method from the XLANGMessageContext:
Use the XLANGMessageContext (Orchestration scenario)
In your orchestration, create a BreHelperComponent.XLANGMessageContext valiable called xlangMessageContext, and construct it in an Expression shape:
xlangMessageContext = new BreHelperComponent.XLANGMessageContext(myMessage);
Lastly add a CallRules shape and provide the parameters:
You can download the sample here.
HTH
Mikael
Blog Post by: wmmihaa
by community-syndication | Sep 15, 2014 | BizTalk Community Blogs via Syndication
I miss the old BizTalk Hotrod Magazine, of my knowledge, there isn’t no other type of magazine about BizTalk Server. And the only thing we have approximately to that is the Flipboard BizTalk Magazine that I have weekly published throughout these last months. You can find the BizTalkMagazine into Flipboard in in your favorite device […]
Blog Post by: Sandro Pereira
by community-syndication | Sep 11, 2014 | BizTalk Community Blogs via Syndication
Colin Dijkgraaf and myself have released a version of the BizTalk Documenter for BizTalk 2013 and an update for the BizTalk Documenter for BizTalk 2010. These releases fix the following issues and have added some new functionality; Added a WIX installer to the project. Fixed several inner exceptions within the application. Suspend and Terminate orchestration […]
Blog Post by: mbrimble
by community-syndication | Sep 8, 2014 | BizTalk Community Blogs via Syndication
Save the date for BizTalk Summit 2014, which will take place December 3-5 on the Microsoft Campus in Redmond, WA. There will be 300+ partners and customers, so bring your questions, knowledge, and business cards. Agenda Executive keynotes outlining Microsoft vision and roadmap Technical deep-dives with product group and industry experts Product announcements Real-world demonstrations […]
Blog Post by: mepemberton
by community-syndication | Sep 8, 2014 | BizTalk Community Blogs via Syndication
In July, Microsoft ended all support for BizTalk Server 2004. This got us to thinking about the looming end of support for other versions of BizTalk Server: mainstream support for 2006 and 2009 has already ended, and extended support for 2006 (and R2) ends in July 2016: http://social.technet.microsoft.com/wiki/contents/articles/18709.biztalk-server-product-lifecycle.aspx According to Microsoft, extendedsupport differs quite a […]
Blog Post by: mepemberton