Learning Adapters : SAP

With my current client I’ve had a chance to work with the SAP adapter for the first

time, which is a treat since most of my work with BizTalk has revolved around HIPAA

and EDI. So I’ve been working with it for several weeks, and I very much like

the delivery of the adapter with one, glaring gotcha which I’ll discuss.

The way the adapter works is that you can access any iDoc or RFC from SAP by creating

a port configured with identity you will connect with, and then selecting to add items

to your solution and select Add Generated Items… and finally select “Add Adapter

Metadata”. You can then walk through the process of selecting your port and

searching for your RFC or iDoc. When you’ve completed the wizard you will have

a newly generated XSD schema added to your project. Happy days, and off you

go, until deployment time.

You see, when the wizard walked through that process, for an RFC, it generated an

assembly, quietly, in a directory which on most boxes will be : C:\Program Files\Microsoft

BizTalk Adapter v2.0 for mySAP Business Suite\Bin. That assembly is required

for the Adapter to work at runtime, and as such must be included in your deployments.

Add to this pickle that the assembly is not strongly named, so you can’t put it in

the GAC like everything else and life get’s really interesting.

This one caught me completely off guard, and personally I consider this a major flaw

in the design of the adapter. I’ve now added two new items to my “To Do” list.

First, implement Scott Colestock’s deployment framework on my project so I don’t have

to deal with external resources and the BizTalk “Export MSI” functionality.

Second, learn more about the Line of Business Adapter SDK and the new WCF adapters

to systems like SAPthat I attended a talk about at TechEd this year.

Backdoors,Hacks and the TD.NET saga

Backdoors,Hacks and the TD.NET saga

So by now most people would have heard about the ruckus that’s going on in the blogosphere regarding Microsoft and Jamie Cansdale’s TestDriven.NET tool. In case you haven’t heard, the issue, as I read it, is that Jamie found a way to make the TD.NET add-in run inside VS Express and Microsoft sent him a formal letter asking him to stop making this available. The issue Microsoft has is not with TD.NET as an add-in or whether its a free or commercial tool but the fact that it is being used with Express and that’s something they don’t want to encourage and have said that extensibility is disabled by default in Express.


Predictably, this issue raised a lot of hackles in the community and many people took this as an opportunity to aim more broadsides at Microsoft. There were some good points in some blogs (check out one here and look for some of the posts and comments on Oren Eini’s blog here and also Dan Fernandez’s blog -one of the posts being this and Jamie himself lists the communications here) but amongst those pearls I was disappointed (but not surprised) to find just loads of vitriol. Some people see it as a hack and some as a legitimate back-door and some say that if there is an API on the machine, they are going to use it and MS cannot stop them. (By that logic, you could be releasing any additions to windows that were unsupported just because the system DLLs are on c:\ drive, and expect MS to sit back and smile indulgently)


Now let me state first of all that I really appreciate Jamie’s add-in. I cut my teeth on unit testing and TDD with that tool (nowadays i use JetBrains UnitRun), and it was very useful indeed. I can see how using this in express will open up the world of TDD to hobbyist developers and others who don’t use the higher end editions, and this can only be good for the programming community in general. However, i can also see Microsoft’s points. I have written a couple of small add-ins for my team and find VS Extensibility quite easy and the possibilities are almost limitless. If MS were to allow Jamie’s tool, lots of other tool developers will jump on the bandwagon and write add-ins for Express and pretty soon it will become a little Eclipse-like ecosystem on its own. If that happens, where will that leave VS Standard and higher end editions?  (Yes, there is an argument for supporting unit testing in express and exposing newbie’s and non-pro dev’s to good programming practices, but how do you draw the line?)


This is just plain business considerations folks. Microsoft is not running a charity. Sure, there are good groups in MS like PAG who want to make things easier for architects and developers and are producing a ton of free stuff that helps us get better at what we do (yeah, so some people don’t like the patterns and the wizards, but there’s a rather large part of the .net world that does), but MS is first and foremost a business and profit is primary and there’s nothing wrong with that. How will they sell Visual Studio commercial editions if Express could be used to do everything that, say, Team System does? Of course, not all third party add-ins are going to be free and ISV’s are bound to continue the tradition of having some free editions and some paid for ‘rich functionality’ editions, but there are some top notch developers in the open source community who could whistle up some free add-ins that trump the commercial ones. So where will that leave MS? What about all the hard work the IDE team is putting into Orcas and Rosario and whatever comes after? Does it have to be free? (Okay, so I benefit from a corporate MSDN subscription and should i ever have to pay for the tool myself then shelling out for VS,especially some features of VSTS,  would burn a rather large hole in my pocket, but that’s another story).


Express is Microsoft’s entry point into the non-pro developer world. They could have engineered a completely new locked down product where there were no DLLs in the GAC or anything for people to tap into, but perhaps that would have cost more than just stripping out some functionality and making a “lite” edition like Express is. As someone pointed out (cant remember where), this could well result in MS pulling the express line completely and that wouldn’t be good at all.


Anyway, that’s my two cents worth (and no, I’m not getting paid to write this !!). In summary I’d say to these parties , “Jamie, well done with TD.NET and well done on getting a huge groundswell of support especially from some of the more articulate developers around”, “Microsoft, there are folks who understand your position, but it could be made a bit more clear without bringing in lawyers against well meaning developers” and to the general community “Folks, there’s always a wide audience for well written comments no matter whose side they are on. Make a clear stand and stop the sniping and broadsides just because MS is a huge,obvious target.”.


Ciao!!


 

Backdoors,Hacks and the TD.NET saga

Backdoors,Hacks and the TD.NET saga

So by now most people would have heard about the ruckus that’s going on in the blogosphere regarding Microsoft and Jamie Cansdale’s TestDriven.NET tool. In case you haven’t heard, the issue, as I read it, is that Jamie found a way to make the TD.NET add-in run inside VS Express and Microsoft sent him a formal letter asking him to stop making this available. The issue Microsoft has is not with TD.NET as an add-in or whether its a free or commercial tool but the fact that it is being used with Express and that’s something they don’t want to encourage and have said that extensibility is disabled by default in Express.


Predictably, this issue raised a lot of hackles in the community and many people took this as an opportunity to aim more broadsides at Microsoft. There were some good points in some blogs (check out one here and look for some of the posts and comments on Oren Eini’s blog here and also Dan Fernandez’s blog -one of the posts being this and Jamie himself lists the communications here) but amongst those pearls I was disappointed (but not surprised) to find just loads of vitriol. Some people see it as a hack and some as a legitimate back-door and some say that if there is an API on the machine, they are going to use it and MS cannot stop them. (By that logic, you could be releasing any additions to windows that were unsupported just because the system DLLs are on c:\ drive, and expect MS to sit back and smile indulgently)


Now let me state first of all that I really appreciate Jamie’s add-in. I cut my teeth on unit testing and TDD with that tool (nowadays i use JetBrains UnitRun), and it was very useful indeed. I can see how using this in express will open up the world of TDD to hobbyist developers and others who don’t use the higher end editions, and this can only be good for the programming community in general. However, i can also see Microsoft’s points. I have written a couple of small add-ins for my team and find VS Extensibility quite easy and the possibilities are almost limitless. If MS were to allow Jamie’s tool, lots of other tool developers will jump on the bandwagon and write add-ins for Express and pretty soon it will become a little Eclipse-like ecosystem on its own. If that happens, where will that leave VS Standard and higher end editions?  (Yes, there is an argument for supporting unit testing in express and exposing newbie’s and non-pro dev’s to good programming practices, but how do you draw the line?)


This is just plain business considerations folks. Microsoft is not running a charity. Sure, there are good groups in MS like PAG who want to make things easier for architects and developers and are producing a ton of free stuff that helps us get better at what we do (yeah, so some people don’t like the patterns and the wizards, but there’s a rather large part of the .net world that does), but MS is first and foremost a business and profit is primary and there’s nothing wrong with that. How will they sell Visual Studio commercial editions if Express could be used to do everything that, say, Team System does? Of course, not all third party add-ins are going to be free and ISV’s are bound to continue the tradition of having some free editions and some paid for ‘rich functionality’ editions, but there are some top notch developers in the open source community who could whistle up some free add-ins that trump the commercial ones. So where will that leave MS? What about all the hard work the IDE team is putting into Orcas and Rosario and whatever comes after? Does it have to be free? (Okay, so I benefit from a corporate MSDN subscription and should i ever have to pay for the tool myself then shelling out for VS,especially some features of VSTS,  would burn a rather large hole in my pocket, but that’s another story).


Express is Microsoft’s entry point into the non-pro developer world. They could have engineered a completely new locked down product where there were no DLLs in the GAC or anything for people to tap into, but perhaps that would have cost more than just stripping out some functionality and making a “lite” edition like Express is. As someone pointed out (cant remember where), this could well result in MS pulling the express line completely and that wouldn’t be good at all.


Anyway, that’s my two cents worth (and no, I’m not getting paid to write this !!). In summary I’d say to these parties , “Jamie, well done with TD.NET and well done on getting a huge groundswell of support especially from some of the more articulate developers around”, “Microsoft, there are folks who understand your position, but it could be made a bit more clear without bringing in lawyers against well meaning developers” and to the general community “Folks, there’s always a wide audience for well written comments no matter whose side they are on. Make a clear stand and stop the sniping and broadsides just because MS is a huge,obvious target.”.


Ciao!!


 

BTSR2: How to turn a BizTalk WCF Published Service into a MEX point as well

Sometimes when you have a published WCF Service, you may just want to allow that service
to provide a description about itself – rather than go through yet another wizard
(re-run the WCF Publishing wizard) to expose out some metadata.

I’ve been doing alot of R2 lately and this exact problem came up. Fortunately I found
a quick and easy way.

Simply add the following lines to your Web.Config before the </Configuration>
tag
(take it out when you’re finished)

 

<system.serviceModel>
<behaviors>
<serviceBehaviors>
<behavior name=”ServiceBehaviorConfiguration”>
<serviceDebug httpHelpPageEnabled=”true” httpsHelpPageEnabled=”false” includeExceptionDetailInFaults=”false”
/>
<serviceMetadata httpGetEnabled=”true” httpsGetEnabled=”false” />
</behavior>
</serviceBehaviors>
</behaviors>
<services>
<!– Note: the service name must match the configuration name for the service implementation.
–>
<service name=”Microsoft.BizTalk.Adapter.Wcf.Runtime.BizTalkServiceInstance” behaviorConfiguration=”ServiceBehaviorConfiguration”>
<endpoint name=”HttpMexEndpoint” address=”mex” binding=”mexHttpBinding” bindingConfiguration=””
contract=”IMetadataExchange” />
<!–<endpoint name=”HttpsMexEndpoint” address=”mex” binding=”mexHttpsBinding”
bindingConfiguration=”” contract=”IMetadataExchange” />–>
</service>
</services>
</system.serviceModel>

 

It doesn’t get easier – enjoy!

Debugging into the .NET XmlSerializer

I’ve had several occasions now where someone with Sogeti or someone at a client has

had a “truly mysterious” problem where the XmlSerializer was throwing an error which

the programmer simply couldn’t understand. When situations like this arise,

I find myself reaching for a great

post written by Scott Hanselman on this issue which I will repeat the meat of

which here so that I’ve got a copy of my own.

If you find yourself needing to debug the code generated by the XmlSerializer to serialize

or deserialize your type, here is what you need to do:

1. Modify your app.config or web.config to include the following:


               1:

              <?

              xml

              version

              ="1.0"

              encoding

              ="utf-8" ?>

               2:

              <

              configuration

              >

            

               3:

              <

              system.diagnostics

              >

            

               4:

              <

              switches

              >

            

               5:

              <

              add

              name

              ="XmlSerialization.Compilation"

              value

              ="1"

              />

            

               6:

              </

              switches

              >

            

               7:

              </

              system.diagnostics

              >

            

               8:

              </

              configuration

              >

            

2. Recompile your application and set a break point just after you create your XmlSerializer.

3. Open the directory “C:\Documents and Settings\[username]\Local Settings\Temp”

4. Find the .CS file with the most recent timestamp, it will have a random file name.

5. Open that file in the same Visual Studio you’ve got debugging, and set a break

point.

6. Debug to your hearts content.

Important to remember at this point is that this code is generated by the system and

is meant to be fast, not friendly. You’ll need to be very familiar with the

XmlReader object or you won’t understand how it is doing what it is doing. Also

realize that you can’t control that code, you can only control the attributes on the

Type you gave it, and from that it will generate the code as it sees fit.

Side Note : One of the classic performance mistakes I see people

make when they start doing a lot of XML serialization is to create the XmlSerializer

object every time they need one. The constructor of the XmlSerializer

is the most expensive part of it’s operations. It is there that the code is

generated which you are debugging above, and so once you’ve created an XmlSerializer

if you’ve got a reasonable expectation of needing it again then keep it around!

Well Well Well

First of all I want to apologise… SORRY!… to the 50+ people that attended last nights .Net user group in Auckland. I came down with a migraine less than an hour before I was due to present and Sean stepped in to deliver the session. Talking to Sean today he enjoyed the session and fielded some great questions. Sean said he will post his links shortly.


On another note I see Dr Sneath has done a great post demo’ing the power of Silverlight Video (who needs blink when you have skew 😉