I am using BizTalk MAP and inside BizTalk map I am using table looping, table extractor, Scripting, looping functoids.
The same can be achieved in BizTalk map by referencing XSLT.
so Performance wise, which method would be better using BizTalk Map or BizTalk map referencing XSLT.
In fact, your visual BizTalk map created with the BizTalk mapper, is XSLT. Only your functoids are libraries/functions which may be either XSLT or inline C# code. One way you can check this is to right click your .btm map and click 'validate'. In the output window, you will see the link to your XSLT file.
Performance is very tricky with XSLT. You can write your XSLT in a very good way or in a way that it's not meant to be used.
For a pretty basic mapping, performance differences will be there, but will be pretty minor (if any at all). As Dijkgraaf says: the only way to check this, is to test it.
If your current implementation gives you performance issues, try writing it purely into XSLT, which is very optimized either way. Try taking different approaches/techniques.
In general, I would always recommend writing XSLT instead of using the mapper, but let's be honest: this is personal preference.
I wrote a blog post on this, check it out here: https://pvandenheede.wordpress.com/2016/09/20/the-case-for-xslt/
XSLT benefits
Import generic or common stylesheets
Use common templates if your schemas are lined up
Inline comments
Disable (comment out) code blocks during debugging
Easier review
Tracking changes in your source repository is possible
Merge from branches is possible
I'm always in favor of using XSLT, only reason Microsoft created functoids and biztalk map, so developers will just do drag and drop. If you're not interested learning XSLT at all.
I'm might be the strange one in favor of using the mapping tool, as said it also produces XSLT.
I think its easier to talk about what is happening in the map with colleagues, since it's visualized, and easier for others to maintain, since not all are that used of coding XSLT.
The only three times I had performance issus with the generated XSLT was
Using one XML as a lookup table in a two incoming XML map - A bug in BizTalk 2006, solved with 2006 R2.
When getting connection strings from SSO - Solved by moving the Script to a global Functiod running once
Using Cumulative Maximum - solved by this method
i think it depends of situation but bizTalk create a lot of variables, code, etc when you create a map using map GUI. I have an experience when i made a map in a map GUI but then just cleared it and leaved in XSLT.
Related
I am trying to use Saxon to programmatically generate an XSLT. This is a similar question to Create xslt files programmatically, but as there was no acceptable answer to that question I am asking again, specifically around Saxon which at one point claimed to support this.
According to http://saxon.sourceforge.net/saxon7.0/api-guide.html, "This document describes how to use Saxon as a Java class library, without making any use of XSLT stylesheets."
(answering the other question I referred to above) and then serialize that to a stylesheet that could then be reloaded and executed later, but I already pretty much figured out that isn't going to happen.
If Saxon isn't the answer, what Java library will support any of this?
By the way, doing any and all of this using .Net is trivial. Unfortunately I need a Java solution for this.
Any help is greatly appreciated.
Well, for a start, there have been 26 major releases and innumerable maintenance releases of Saxon since release 7.0, so forget anything you read there.
It's not clear from your question whether you want to write your XSLT code generator in Java or in XSLT. I can't see why you would want to do it in Java rather than XSLT, but neither is difficult. The main problem with your question is that you don't explain why you think it's a problem. Generating an XSLT stylesheet is just like generating any other XML document: what's the problem?
I figured this out a while ago, and thought I would share my answer. This may or may be an answer for Create xslt files programmatically as well, but since that was not my question, I won't assume that.
The answer is not to use XSLT (or Saxon) at all. Originally I wanted an API with which to generate an XSLT model where the rules for transforming a particular (xml) tree structure are known programmatically. Then the model could be persisted as a style sheet so that it could be reloaded and used to transform another tree with the same structure again. Sure I could programmatically create a DOM containing an XSLT style sheet document, but why would I want to? It's inefficient for one - creating and saving a DOM with all the XSLT syntax (tedious), and then reading it using SAXON, etc. I'd rather have an API that natively understands XSLT - maybe one that has an XSLT model that can just be programmed and then serialized?
Anyway, the answer to my problem is just to use SAX. Since I know the particular transformation rules for my tree programmatically, I simply created a handler that processes the stream using the rules, and I'm done. In the end there's no XSLT style sheet that can live outside the program, but I'll live with that.
And I take back what I said about .Net supporting my first approach. I thought it would so it's just a reminder to check your assumptions before you post.
By the way, an answer to my question suggested that it was easy to accomplish but rather than outline how to do it, I was just questioned why I would want to. Can we at least try to answer a question if we also feel we need to ask someone why they are asking a question?
My requirements are that I provide a way for Business Analyst-types to specify XSLT-like transformations without the complexity of XSLT or XPath. Basically there are incoming XML documents and the client needs to be able to specify situations where elements/subtrees should be edited/removed/replaced/added. It will essentially be a rules engine for applying XSL transformations.
My first approach was to come up with a DSL using an ANTLR grammar to parse into Java code but I get the feeling I'm overlooking the KISS approach. I've scoured the web but haven't been able to find any existing libraries/frameworks for providing a simple interface for applying transformations. I feel like I'm missing the obvious solution but can't put my finger on it.
Have you looked at Altova MapForce?
At present we are using BizTalk as an XSLT generator. We map two XSDs together and then have BizTalk generate and XSLT that we use in another app. Shortly we will be getting rid of BizTalk and are on the hunt for a new program that will provide us this functionality.
Thanks!
Sad to hear you are loosing BizTalk.
I have tried MapForce from Altova, more info here, it has similar functionality as BizTalk mapper.
I completely agree with Martin.
It's good that you are moving out of BizTalk if you are only using it as an XSLT generator.Using BizTalk just as an XSLT generator is like using YAG laser to cut through butter.(http://www.youtube.com/watch?v=aRZ8TlvH2gc)
I am in the preliminary stages of planning a project with a client to redo their current website. I took a look at their current site to see what issues they are currently dealing with and upon inspection I noticed that every page is being rendered entirely using XSLT. I am familiar with XSLT, I have used it to render custom controls that need to be refreshed often on the client-side, but never to render an entire page.
Help me become less ignorant, what could be the reasoning behind this? What benefits or disadvantages does this bring to the table?
Server-side:
Advantages:
Clean, concise templates
An easy way to process XML data into HTML
Reasonably fast
Disadvantages:
Programming model unfamiliar and uncomfortable for many procedural-language programmers
Awkward if some or all source data is not in XML
Can be very slow when not used carefully (small changes can have large repercussions)
Client-side:
Advantages:
A convenient way to off-load processing onto client code, where scripts can potentially have much better knowledge of how best to format the resulting HTML.
Disadvantages:
Browser support is all over the map.
Google won't thank you.
Sounds like they did it because they knew XSL-T very well and already had XML data on hand.
I wouldn't like the solution myself. XSL-T isn't the easiest thing to read or write. It doesn't lend itself well to visualizing how a page will look. It cuts designers and web developers out of the process. And it doesn't internationalize well. There's nothing equivalent to Java resource bundles that can pull out locale specific information. I don't consider cut & paste a good solution.
XSLT on client side
Disables progressive rendering. User won't see anything at all until entire stylesheet and data is loaded completely.
Not supported by search engines and other crawlers. They'll see raw XML.
Not supported by older/less advanced browsers.
XSLT in general
Unless you carefully design your stylesheets, they may quickly become difficult to maintain:
with numerous templates it may be very difficult to figure out which templates are applied.
verbosity of XSLT and XML syntax make it hard to understand anything at glance.
XPath tricks are tempting, but nightmare to modify later.
I think XSLT is great when built the right way(We use a framework of templates at work).
Sounds like the All-singing-all-dancing XML fetish.
Since you can do anything with XSLT, might as well do everything. I've had people ask why a data warehouse isn't just XSLT transforms between input, data mart and reports.
Advantage. Everything's in XML.
Disadvantages.
Not very readable. Your page templates are bound up as XSLT transformations with confusing looping and conditional processing features.
Any change to page templates requires an XSLT expert, in addition to the graphic designer who created (and debugged) the HTML and CSS.
Biggest benefit: platform neutral way to render xml
Biggest disadvantage xsl is difficult to maintain
I've once had to work with an xsl over 4,000 lines long that also includes several other xsl templates. Now that was hard to work with!
The answers above provide a good survey of some of the advantages and disadvantages of XSLT. I'd like to add another disadvantage. We have found that you pretty quickly run into scalability issues when using XSLT for moderately large datasets.
When processing XML files, XSLT must load the entire document into memory. With Xalan, this consumes roughly 10x the size of the input file (saxon has an alternative DOM implementation that uses less memory). If any of your input datasets grow beyond a couple of hundred megabytes, your XSLT processor might just flake out.
I'm invoking one of SharePoint's web service APIs that returns a CAML fragment. I've searched the interweb far and wide but I've been unable to figure out how to make this CAML fragment to render as "normal" HTML that I can render in a more sane environment like Plumtree, WLP, Liferay or any other portal besides SharePoint.
Without a way to do this, I'm wondering why Microsoft wrote SharePoint web service calls that return CAML in the first place. Web services are for interoperability and it seems the CAML is only valid within a WebPart running within SharePoint. [Note to Bill and Steve: that's not interoperability.]
If I can't do anything with the CAML that comes back, I'm just going to call a different web service that returns only data and then write my own UI. I was hoping for an easier path. Any suggestions would be greatly appreciated.
The CAML is still XML and as mentioned, XSLT will be able to render it as HTML. The actual gnraly nested OR/AND structure of CAML is a whole nother issue.
That would require unrolling the CAML structure and displaying it in a way that normal people understand.
Unfortunately, the XSLT language is unsuitable for unrolling nested structures like this (it has no stack). It is possible, but having done it I recommend strongly using another language to parse and unroll the CAML.
I have yet to see a CAML to SQL conversion code. Sounds like a great Codeplex project.
So in summary... you are a bit stuffed with CAML. While it is XML, it's structure is unsuited to use in any other query language.
You could send the CAML through an XSLT stylesheet to generate HTML or XHTML.
Edit:
Considering your first question (why SharePoint returns CAML from some of its web services)... who knows? It may be there to support authoring tools such as SharePoint designer. But it seems clear from the dearth of documentation and tools that CAML is a more-or-less internal SharePoint thing. At present, performing CAML-to-HTML conversion would require either somehow accessing the CAML rendering engine within SharePoint, or re-implementing it. Neither option is attractive.
I think that your conclusion (calling data-returning web services and rendering the HTML yourself) is probably your best bet.