.
BizTalk: What features we would like to see in future releases
I created the list of features and separated it into parts. One is from the global, crazy things than never be implemented. But why don’t imagine? Second one is from the small things.
Let start from the big, crazy things:
More flexibility in the deployment and licensing.
What I mean:
1) Why don't move the BizTalk as a product to cheap segment? (cheap? No, let's talk about bigger)
a) BizTalk + SQL Express on one box. Then creating a farm of the BizTalk applications would be easier. Load Balancing is moved outside, before the farm. Maybe create a separate product the "BizTalk load balancer"?
b) Moreover, ship the preconfigured VHD with BizTalk + SQL Express + Windows Server. With possibility to create the farm from these VHDs. (Not so easy because now we have strict limit to the SQL and BizTalk server names, and that limit should be fixed anyway.)
2) Why don't move to the expensive segment?
a) Shift to the Windows HPC? What about this? One time the BizTalk was pioneered as the first enterprise level product by Microsoft, created on .NET. Using the HPC methods to get rid of SQL completely, perform all persistency in memory to get super-low latency product.
3) Reiterate the architecture with all spectrum new Microsoft technologies. Is it possible to extract the MessageEngine, the OrchestrationEngine, and the UnifiedInputOutput Engine to separate products?
4) At last extract the BRE to separate product or free library! Now it is dead. Give BRE a shock treatment.
5) Redesign the error processing for different stages of the message processing. Now there are different approaches are used in many places or nothing at all.
6) Extract the LOB Adapters to separate product on the “buy if you need it” basis or to the free library. Create the Internet store and sell adapters for small money to everyone not only to the buyers of the BizTalk. Sell them not in packages but per adapter.
Now the small things:
Many years there were no improvements in very basic things, the things the developers are using in everyday tasks. I mean: adapters: File, SQL; pipelines; schema and map editors; additional shapes in Orchestrations, etc.
1. Adapters:
a. File adapter (for example): add the possibility to use the file names to order delivery (process files in the sorted order, many variations J ); implement the file receive filters with regEx on the file names; add possibility to copy files to other folder after consuming (to make some sort audit/resubmit storage, in forums this question is repeated and repeated, "How we could make a copy of the original files?")
b. SQL adapter: OMG, there should be many changes in real-time functions and much more improvements in the design-time appearance. I'd prefer to use not the standard Wizard to generate SQL port artifacts but some sort rich-UI window to set up different stages of artifact creation and the real-time parameters.
I am sure the brainstorm by BizTalk MVP should generate a lot of good ideas.
c. Additional adapters: like Task Scheduler; Nope; Fan-out/Garbage (to consume messages without subscribers in the pub/sub application); PowerShell (for additional processing of the input/output messages). Brainstorm this! Buy these adapters from the third-parts, unify them and include to the standard package.
d. Please, make InfoPath integration with BizTalk easy as hell!!!! (Isn't it a prime purpose of InfoPath??? To integrate the BizTalk with human?)
2. Pipelines (pipeline components): where are? the xml <-> PDF ; zip/unzip ; map (yeah! what is wrong with it?); different coders/decoders; symbol (regex) replacement (for EDI processing it MUST be!); PowerShell (for additional processing of the input/output messages); "create message" pipeline; Excel/Word ; Html ; simple EDI (to very basic EDI processing); promote properties from the text; etc. . Brainstorm this!
3. Add the error processing to the standard interfaces of the custom pipeline components.
4. Transmitting raw/binary data. Frequently we only use the BizTalk to transfer and route the documents (messages) without transformation. Now it is the second-class citizen scenario.
5. Orchestrations: additional shapes as: CreateMessage !!!; throwEvent; Pipeline transformation (?).
Make shapes resizable, otherwise we should use odd methods to make the Orchestration more descriptive. How we could show Orchestration to business people if we cannot add enough text to shapes???? Add color to shapes.
Make the Expression Editor window resizable, dockable, fully InteliSensed, etc. !!!!!!!!!!!!!!!!!!
6. Schema editor: Use the schema node icons for more useful information, definitely, for cardinality (say, different colors for "max occurs = *", for "min occurs = 0"). Maybe add separate window for the referenced (included) schemas?
7. Map editor: add functoids [IfElse]... Make improvements to the Script functoid!!! Separate to InlineScript; ExternalScript (ExternalMethod?); XsltScript...; make InteliSense to the Inline Script and Xslt script windows. Use the source/target node icons to more usefull information. See http://geekswithblogs.net/LeonidGaneline/archive/2005/12/23/64004.aspx - it is an old list but still actual.
8. Ports: Please, make ports the first-class artifact as an Orch. Why we should use the orchestration assembly just to store the port type??? Why do we use the "logical port" term in Orchestration editor? It is not a port, it is just an endpoint. Orchestration has the endpoints and the Port has the endpoints. My perception it should be big redesign of the "port part" of the BizTalk architecture. Right now it is a mix of adapters, pipelines, maps, etc. without strict regulation, strict design. This mix is very static, could not be used in structured way to improve the development.
The question to us was: 1) What was/is THE GOOD stuff about the area? 2) What is just plain BAD? 3) What is UGLY about the feature area e.g. if you were developing this feature what would you do to improve it.
I am sorry but I used the same words. To me “UGLY” and “BAD” are just synonyms for ”rudimentary implemented” and “implemented in beta version”.
1) Monitoring, operations. Now it is UGLY. No real real-time :). See how it works on HPC Windows, for example.
2) Debugging is plain BAD.
4) To me BAM is kind of partly implemented. Run-time is very good. Design-time is BAD.
5) ESB. IMHO if the BizTalk gets the Web-service (or metadata) repository, it has ALL ESB functionality and could be named ESB to business people. MVPs discussed this many times on the Summit.
6) Of course, low latency must be implemented.