Microsoft BizTalk Server vNext (after 2009 R2) - Feature Request

Question

All,

This post is not a question; it’s more of asking for feed back and future request. The product team is always looking for feed back to facilitate the future direction of the product. Some of us as BizTalk Server MVP’s/partners get that privilege to work with the product team closely to give our feedback regularly based on our real world experience. But I believe there is a much wider BizTalk community out there working on closed door project that tests the strength of the product to extreme levels.

I would like those passionate people to come forward and put their feature request. Let’s use the power of StackOverflow to help us here. We can vote up and down on each feature request, and see what's going to top the chart. I hope this will be a useful exercise.

Updated 24th Feb: If you got more than one request, please post it as separate answers. So, its easy to vote against them.

Answer 1

Support for publishing and consuming RESTful resource endpoints.

Answer 2

Feature: Mapper Improvement

A graphical mapping tool that is capable of handling complex transformations. For example, most EDI transformations require writing custom XSLT code because the looping requirements are more than the graphical mapper can handle.

Answer 3

Feature: Better VS Integration

Better integration with Visual Studio for a more productive environment. The latest version (Biztalk 2009) has serious issues when working in VS 2008 (file locking, slow build process, etc).

Answer 4

Feature: Better VS Integration

Debugging inside the orchestrations like in the expression shapes, maps etc.

Answer 5

Feature: Reusable Maps

I have always felt that the MAP is not really very mainatainable. Though the tools provided are great for developer, It becomes a big problem when re-using comes into picture. There should be some be way where the MAP tool should start supporting Sub - Maps (by XSL:Include and XSL:Import). That will make the development more robust for any type of application.

Saravana kumar, If you can make this happen with the product team, nothing like that.

Answer 6

Feature: Mapper Improvement

WE Had a flat of 19000 fields we wanted to generate schema using schema generation wizard nor able to map using Biztalk mapper for mapping so wuld like the support for large size schemas in the mapper

Answer 7

Feature: BRE Improvements

I believe working with BRE should be improve coz when i develop multiple vocabulary at development time which is hectic to merge.

Need the BRE RuleBurst integration with BizTalk. http://social.msdn.microsoft.com/Forums/en/biztalkgeneral/thread/d4569d56-bd69-497e-92ea-c865ff58cf92

I wish to get BRE portal similar like BAM portal.

Answer 8

1. More Adapters for example ODBC, Sybase, Excel, DBase, FoxPro etc.
2. Beeing able to execute EDI receive pipelines in Orchestrations for better flow control..
3. More elaborate port scheduling. ( You know Mo-Fri 07:00 to 23:00 sat-sun Off )
4. A receive adapter that polls a webservice.
5. A new user interface for BAM. (Better / easier query editor )
6. Low Latency support
7. SLA monitor out of the box.
8. BizTalk Documentor included in the package. (Beeing able to generate docs from within BizTalk Administrator Console)

That's it for now..

Answer 9

Where do I start - 1. +1 for low latency.

1. better designers with inheritence support (e.g. designing 1 base process, and inheriting where needed)

2. ability to add custom tasks/shape to Orchs.

3. WF40 interop + support.

4. MAP - access to msg context props.

5. Deeper integration with SharePoint. 7 Better tools for troubleshooting, problem resolution. 8 new BRE rule composer/improvements for import/exporting rules.

6. MUCH better config management between environments such as Dev, stage + Prod.

Let's see how we go with this.....

Answer 10

Feature: Side by Side installation support

I'm surprised not too many of them are discussing about side-by-side installation of BizTalk Server.

Let me explain the scenario: BizTalk is in its 5th generation (2004, 2006, 2006 R2, 2009, 2009 R2) now (ignoring versions prior to 2004). I can see a regular pattern of developers either supporting multiple versions, or they are in the migration path where one system is in production with BizTalk 2006 and they are working on migration project that utilizes 2009 or 2009 R2 etc.

It's a really pain point from developer perspective, the only solution now is to maintain 2 different machines (or VMs) to support this scenario.

It will be a nice feature if BizTalk can support side-by-side installation, similar to Visual Studio.

If we look at the puzzel, VS supports side-by-side installation, multiple sql instances can be installed on the same box. So, I guess its not far off from supporting side by side BizTalk installation.

Answer 11

Feature: Orchestration debugging in VS

I believe debugging of orchestrations inside visualstudio will deliver a richer development experience. No switching to other tools etc all from one EDI.

Answer 12

Feature: Better expressions shapes and scripting functoids

better intelisence, code editing in expression shapes, scripting functoids etc. So there will be no need anymore for typing the code outside the expression editor or scripting functoid and pasting it in.

Answer 13

Improved support for SharePoint integration scenarios.

Ex: - create elements in lists - approach to solve multiple polling locations (scalability issue) - archive feature in read allows doc to be moved: this destination folder should be dynamica/dynamically determined --> it also doesn't consider sharepoint 2003/2007 2000 item per-folder limit.

Answer 14

Feature: Improvements to XREF Support

Evolve the API and DB Support with other usage scenarios. Move tables to separate DB.

Answer 15

Feature: Better support for MSDTC transactional scenarios when using objects that access DB inside orchestrations

ex: automated deployment to component services; code skeletons; clearer documentation, etc.

Answer 16

Feature: Low Latency

I know this is going to be one of the most requested feature, so please click on the up voting button if you support it.

Answer 17

Refactor BAM implementation.

Ex: - replace Excel with some other tool (personas never really worked with BAM, the Dev does it all) - replace Office Web Components with other forms of visualization - simplify API's - increase event precision to sub-second - simplify process/sub-process implementation

Answer 18

Followings,

1. Support for Low latency Rich user Interface for Mapping ( current map editor hangs or takes time to load complex schema's)
2. Better tool for Administration ( a fast tool)
3. Better debugging experience.
4. Of Course new User Interface for BAM Portal

Answer 19

Support for XSLT 2.0 in BizTalk mapper.

Answer 20

A resizable/maximisable code editing window for XLANG/s

Answer 21

Feature: Automated Documentation

Maybe more of a VS feature request - render Xml-Documentation without external tools like Sandcastle or NDoc.

Answer 22

Exchange Server WS adapter

Answer 23

Withdrawn Request

Answer 24

I think will be very good if you could choose in the administration time if the orchestration ports are binded direct to the messagebox or binded to the physical ports, instead to have to do this operation in the design time and to have to recompile.

Thats mean, to have the possibility to apply filters to the orchestrations and bind the orchestration ports directly to the messagebox in the administration time.

Answer 25

1) Full C# support in orchestrations expressions (or at least add support for generics)

2) Low latency (a must)

3) More out of the box standard pipeline components

4) Resizable expression code editor, preferably with improved intellisense and syntax highlighting.

5) Improved consistent support for automated deployment rather than the loose collection of command line tools we currently have.

Answer 26

Improved unit testing support

It is currently possible to write unit tests for most parts of a BizTalk application but it is not a trivial task.

External dlls with difficult APIs are needed for things like schemas and maps (that also require some non-intuitive paramaters to use).

Orchestrations are very difficult to unit test.

Mocking of external subsystems requires custom dev to build a supporting framework.

Answer 27

More flexibility in the Pipeline framework

There are several parts of the pipeline framework that it would be great to have more flexibility in.

One example is the disassembly stage - you can have multiple disassemble components but only one will execute.

This becomes a problem when using (for example) the AS2 disassembler that generates an MDN in the disassemble stage. If you also want to parse XML payload you have to either write your own disassemble component that combines two out of the box components, or fall back to a pattern to allow going through the receive pipelines twice.

There are many other places where more flexibility in pipeline processing would be very handy for producing solutions that more accurately reflect business intent.

Answer 28

Please give more testing to the product before getting it to the market. BTS2009 is not fun to work with - VS integration issues, buggy Admin Console, WCF-LOB adapters with obscure documentation... The engine is rock solid though.

Answer 29

1. Better Rule Engine.
2. Improved deployment features (i.e. less downtime during upgrade).
3. Orchestration inheritance.
4. Support for XSLT 2.0 in mapper.
5. Better support for mapping dynamic fields.
6. An improved support for low latency scenarios. I would really like to have a persistancy as an option but not a must.

Edit: splitted mapper features requests to 2 different sections.

Answer 30

expression shapes should function just like asp.net/wpf where you "doubleclick" the shape and it takes you to A CODE BEHIND. I can't tell you how ridiculous I find it that Microsoft/visual studio has had this functionality since at least 2003 (and before if you count products like office 97).

It seems so simple but if you do ANYTHING inside an orchestration with code it gets some half assed code editor.

just pump it out to a .g.cs or a .bt.cs whatever - just not 'in' the expression shape! this can't be hard to implement... it's done in tons of products so steal it already!

Answer 31

MSI files should be "built" and not "emitted" from a running biztalk instance. If I want to create a build script to "emit" my deployment like I can with"Publish Website", it's not possible. This is my number one beef with deployment you have to do the configuration and msi emitting via an actual running instance. I don't know if many other biztalk developers actually have 'biztalk administrators' who are separate from the 'biztalk developer' but for us - WE are the full stack from code to deployment. Requiring it to be 'configured and emitted' leads to missing artifacts, unchecked check boxes etc.

Answer 32

throttling. we should be able to easily control how many running orchestrations/send ports are running concurrently across the group. a lot of times biztalk's scalability can decimate a legacy application and using the current throttling settings does not set a firm cap on total running instances across the group (well i will also plead ignorance but I've not found how to accomplish this across all nodes in a group with a 'built in' feature of biztalk)

Answer 33

Rework the BizTalk Server Administration console. The current treeview style UI is very unfriendly to use. It's not very intuitive and doesn't highlight problem areas easily. I'd like to see a complete redesign using WPF. One where you can see the relationships between each artefact and visualise the flow of messages. This could be expanded then to a live dashboard of running instances, showing where messages were suspended and including other information like performance information. A good UI could allow you to drill down into each artefact to see it's metadata, tracked instances etc.

Answer 34

Hi Folks,

I would like a the WCF adapter for SQL to allow calling SQL stored procedures with MULTIPLE paramaters, where the paramters can be XML data, constants and PROMOTED FIELDS

So, perhaps in the near future, this type of template will work in WCF-Custom. Where the template has access to the BizTalk Property Schema. Notice below we no longer use encoding type of string to the message, will be faster, of course this sort of template will never work now, but nice to have one day? It could be an add in for the Consume Adapter Service BizTalk Project Add-In where you can drag promoted property fields into the template. This should be possible, since the following assembly has direct access to the message and all properties:

System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)

so template below in future would work in WCF-Custom: (If template does not show, check my blog site for it:)

http://www.microsoft.com/schemas/bts2007" encoding="stream"/>

StageParam, StatusParam and IdParam are promoted properties of the message going into the adapter, and this should be possible, the WCF architecture can support this, since they already have the fixed property schema for:

bts-msg-body xmlns="http://www.microsoft.com/schemas/bts2007

I am excited about WCF, but it can be much more powerful with BizTalk if it can hook into Promoted Properties and not encode the message as a string, but default it to a stream.

Why????? Since SQL support XML, there is allot of times where you just want to push XML data into SQL Server avoiding Orchestrations and updategrams/insertgrams etc.

I blog covering this is here: http://grounding.co.za/blogs/romiko/archive/2010/03/01/windows-communication-foundation-biztalk-adapter-wcf-custom.aspx

I know allot of BizTalkers love orchestrations and rightfully so, however there are times when they should be avoided, for example using them to map data to SQL can sometimes be an overhead that really is not needed if storing XML data directly in SQL and you need additional paramters.

HTH :)

Answer 35

1. Enhanced BAM features: More investment in BAM features, making them easier to use. I'd like a new property field included on all shapes in the toolbox called "BAM Enabled or Report to BAM (True|False)", something like the property called "Report to Analyst". These properties could act like a distingushed/promoted fields and be accessible from a new BAM portal, where you can define and build BAM views. I would be as easy as creating reports in Reporting Services and it would make things more productive/effective.

2. Decouple IIS dependency on Biztalk when it comes to publishing schemas/orchestrations as WCF/ASMX services. Today Biztalk needs to be installed on the IIS server you are going to publish the web service to, else the service will not compile... This would be handy when security is an issue.

3. Side-by-side versioning of applications made easier

4. Better administrative features both in Admin console and SCOM. Look at what Amberpoint or SOA Software have done...lots of good ideas to build on there.

Answer 36

Make mapping tool support and assist in constructing xslt rather than trying to hide it. We always run into the problem where the complexity of the mapping is not implementable in pure xslt.

The aim of the mapper should be to educate ppl on xslt not try to hide it.

Answer 37

We developed a Custom ASP.NET mapping tool. That can use an XSLT or use a custom mapping feature which is stream based. This has been a life saver for us. We have over 350 file feeds, all of them are now mapped by users and no deployments needs to be done. if we relied on the BizTalk Mapper, it would have been a nightmare to deploy a dll for every feed created.

Would be cool to have a ASP.NET mapping.

Answer 38

There should be a out-of-box MS Excel adapter.

Answer 39

Feature: Mapper Improvement

The ability to copy and paste functoids within the mapper

Answer 40

Feature: Mapper Improvement

The ability to resize functoid windows (for example the scripting functoid window) so that all text is visible without scrolling.

Answer 41

Feature: BizTalk Expression Editor Improvement

The ability to resize window so that all text is visible without scrolling.

Answer 42

Feature: Build & Deploy Framework

From what I can gather, even BizTalk expert consultants spend at least two days on a new project, writing scripts to automate the build and deploy environment. If some of these tasks could be wrapped into BizTalk itself, it would be a big win for standardization as well as helping newcomers get on track faster (eg. better support for cleaning and redeploying an entire project from scratch AND suggested standardized project layouts to maximize reusability). In general, I'm just asking for a little more transparency about how the system works from the people who know it best.