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)
Related
I'm currently trying to give my WSDLs some design by attaching a stylesheet to it, so that it could be readable by a technical but non-dev human being.
I was thinking I could add some XSLT to my generated spring-ws dynamic-wsdl so that it could be sent to the browser as a pure html (and not xml as it is). But I couldn't find any way to add xslt to the generated wsdl
Can you see any way to accomplish that ?
We are planning to use Saxonica EE (yet to buy) in Spring Boot microservice on Cloud Foundry and we want to store the XSLT compiled version in XML in Redis cache so that when do transformation it would be less time consuming, I have below questions, can you please guide me in right direction.
how can we deploy Saxon EE libs with licence to the cloud, any standard practice need to be followed.
is it possible to get the XSLT compiled code in XML format so that I can store in Redis cache, is this approach make sense (if there is any change in XSLT I will re-compile every time)
Any java programming samples, we use xsl:include heavily in all xsls , if there is any example for the same use-case would be great.
For the commercial questions regarding licensing for cloud deployment, that's out of scope for StackOverflow - please contact Saxonica directly to discuss this.
Saxon-EE can compile a stylesheet to a SEF file which is indeed an XML format, but I've no idea whether storing the compiled stylesheets in Redis makes any sense.
If you have a problem using xsl:include, I suggest you raise it as a separate question. A general request for advice on using a particular feature isn't likely to elicit helpful responses - StackOverflow works best if you have a specific technical question, or a specific technical problem. (If you want general advice, my XSLT reference book has about 4 pages on xsl:include, with examples).
I recommend you to start by getting the basic foundation of clarity in place as described below:
About choosing Redis for storage :
If your going for Redis as storage you normally would have to serialize your (XSLT processed) output into XML or JSON prior to storing it into Redis. This means also that any time you want to access the data in a more human-friendly readable way, you would have to deserialize the Redis string.
Answers on your bulleted questions (in relation to XSLT) :
[1] Cloud deployment: Even if you would like to use cloud solutions you would still need to define on which server you would like to install Java/SDK and Saxon libraries (jar). In terms of details around license for cloud solution, I would refer to the company Saxonica.
[2] Need of compiling: Saxon XSLT is not normally being compiled by user (unless there is a reason for it). I suspect when you say "compiled" in this bullet that you mean the transformation process, using a source XML, XSLT for processing and getting an output XML. - If so, you can set which output format you want (XML/HTML/XHTML). Every time you change something in your source- or XSL file, you would need to run XSLT to see the change in the XML output file.
[3] Need of Java samples: You do not need Java knowledge to build XSL stylesheet files. The Java comes into the picture if you choose to run on Java you would need to setup Java/SDK on the machine that would run Saxon XSLT. After the setup (Java/SDK and XSLT) you can choose between calling XSLT from a terminal or create scripts that would call XSLT (I use bash scripts in Linux).
I recommend that you start using an online XSLT tool meanwhile you solve your Java environment and Saxon XSLT. This way you can build up your XSL files or test any of your existing XSL files in order to adjust them to your needs.
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.
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?
Does anyone know if there exists something like XMLUnit for C++? I'm looking for an easy way to check nodes, values, etc in a XML output. We are using Google test in Visual Studio but I suppose any library that makes the work easier will be enough.
I'm using Xerces as an XML parser but XMLUnit (http://xmlunit.sourceforge.net/) has some features wrapped over the XML parser that are very useful for unit testing. For example, asserts using XPath expressions, functions to compare two "similar" XMLs, etc.
I have used a combination of Xerces and CPPUnit to accomplish this in the past. In my test cases I would create a DOM object with the Xerces API in the setUp() function. This DOM would represent my expected results. In the test case itself I would then read the XML file and the class under test would populate a DOM object representing the contents of the file. To check equality I would walk through the two DOM trees via the Xerces API (DOMTreeWalker) and use CPPUnit assertions as I compared the contents of the DOM nodes. It was a bit tedious but there were no frameworks available at the time that could mimic XmlUnit. I would imagine that Google Test would work just as well as CPPUnit for accomplishing this task.
The Xerces API has some support for XPath expressions:
http://xerces.apache.org/xerces-c/faq-parse-3.html#faq-2
For validation you would need to set up an error handler as mentioned here and incorporate it into your test case:
Validating document in Xerces C++
For XSLT transform checking you would need to use Xalan. It works with Xerces so I wouldn't anticipate any major difficulties:
http://xalan.apache.org/old/xalan-c/index.html
I was not able to locate any obvious products that packaged XMLUnit-like operations in C++. So the answer is I think you will have to roll your own. Good luck.
I really like http://pugixml.org/
It:
is stable
is extremely fast
has great documentation and sample code
is licensed under the MIT license
is very STL friendly
is still quite an active project
has great support for xpath
You can use tinyxml package here: tinyxml
I'm working with it and it's quite friendly and bug free.
It's an xml handling.
I guess it wasn't designed for unit testing, but you can use it to check/test your xml files.
It as expected loads the xml into a DOM object and supplies a nice API to run on the nodes.
Gal
Xerces at http://xerces.apache.org/xerces-c/i pretty full featured, has a C++ interface and produces good error messages, which several other XML parsers don't do so well. Having said that, it's pretty big & I've wound up using my own wrapper round the C parser Expat.
I'm currently using libxml++ for a personal project of mine.
I use Boost property_tree for xml, easy to use, pretty robust and works well with Boost unit test framework.