This blog series is about extending EPiServer Template Foundation (ETF) with a WCF service that can be accessed with REST and returns JSON. This is the final part in a series of three. The first and…
Daniel Berg’s blog about ASP.NET, EPiServer, SharePoint, BizTalk
This blog series is about extending EPiServer Template Foundation (ETF) with a WCF service that can be accessed with REST and returns JSON. This is the second part in a series of three. The first…
Daniel Berg’s blog about ASP.NET, EPiServer, SharePoint, BizTalk
This blog series is about extending EPiServer Template Foundation (ETF) with a WCF service that can be accessed with REST and returns JSON. A’lot of acronyms means it’s really cool – right? Let’s get…
Daniel Berg’s blog about ASP.NET, EPiServer, SharePoint, BizTalk
Over the last week there has been a lot of confusion/concern about Silverlight that occurred from an interview given at the PDC conference last week. A few days ago Bob Muglia (President of our Server and Tools Division) posted a blog post on the Silverlight Team blog that helped clarify what he said in the interview that caused the controversy. You can read his post here.
Three of the things that he explicitly said in the interview (and which were reported in the article – but unfortunately lost in the public reaction to it) were:
In his blog post he expanded more to discuss some of the core areas we are focusing on with Silverlight going forward:
The “strategy shift” comment he made in the interview was intended to be about us increasing our focus on the above three areas as key scenarios where we think we can really differentiate and add a ton of value with Silverlight. These are not new areas but rather core things we’ve always focused on with Silverlight and are the primary scenarios customers use it for today. You’ll see even more focus on these areas in future Silverlight releases.
Where our strategy has shifted since we first started working on Silverlight is that the number of Internet connected devices out there in the world has increased significantly in the last 2 years (not just with phones, but also with embedded devices like TVs), and trying to get a single implementation of a runtime across all of them is no longer really practical (many of the devices are closed platforms that do not allow extensibility). This is true for any single runtime implementation – whether it is Silverlight, Flash, Java, Cocoa, a specific HTML5 implementation, or something else. If people want to have maximum reach across *all* devices then HTML will provide the broadest reach (this is true with HTML4 today – and will eventually be true with HTML5 in the future). One of the things we as a company are working hard on is making sure we have the best browser and HTML5 implementation on Windows devices through the great work we are doing with IE9.
This by no means should be interpreted as Silverlight not being important. We all know the importance of having the richest possible experiences for key platforms and form-factors, and the value that consumers (both end-users and enterprise) attribute to it. This is not just a true statement for Microsoft platforms – but has obviously been demonstrated by many others as well (Apple being an example). Silverlight is a strategic technology from Microsoft that enables developers to build those, and we think our investments and focus (in particular with the above three areas) provides us with an incredibly compelling and differentiated platform to do so. We’ll be sharing more details about some of the great Silverlight improvements coming in the future soon.
Hope this helps provide some clarity – and apologies again for the confusion and angst this past week,
Scott
P.S. I have been on paternity leave the last few weeks taking care of a new baby which is why I’ve been offline recently. My blogging/twittering will increase again shortly.
Error: 1 (Field level error)
SegmentID: CLM
Position in TS: 22
Data Element ID: CLM02__TotalClaimChargeAmount
Position in Segment: 2
Data Value: 8888.99
6: Invalid character in data element
This can be resolved by changing the party definition to allow leading and trailing spaces and zeros.
I’m back in the NUnit world after a long time. We are looking at packaging up the NUnit GUI along with some BizUnit tests for my current gig so that we have a set of integration tests to run on the rigs. Ironically, the project isnt even a BizTalk one, but BizUnit is still a […]
One of the problems with the current version of Windows Workflow Foundation is how to handle different versions of your workflows. With short running workflows this is no big deal, workflows do whatever they are supposed to do and finish, and you can deploy a newer updated version of your XAMLX files whenever you want. Provided the public facing SOAP interface doesn’t change no one will notice a difference and everything will work just fine.
However as soon as we get into long running workflows and the SQL Workflow Instance Store things get quite a bit more complicated. As soon as you add or remove activities from your XAMLX, the workflow service definition, you can no longer load any of the workflow instances currently saved in the SQL Workflow Instance Store. This is a bit of a problem because it would mean you would either have to wait until all workflows are finished before upgrading you workflow definition or you would have to abort all running instances, neither is an acceptable solution in most cases.
How workflow data is stored
The SQL Workflow Instance Store keeps track of the WCF address used to start a workflow and stores that along with the actual workflow state. It uses this data to differentiate between different workflow service definition. And this can actually help us fixing our versioning problem, just leave the existing workflow definition as is and create a new one alongside it with the new definition.
So this solves the problem of separating the state of each workflow version but means that the client application needs to be updated each time a new version of the workflow service is deployed. Not only that but the client needs to keep track of which workflow was started using which service and send each future requests to the same address. This puts a big extra burden on our client app and that is something we don’t want.
The WCF 4 RoutingService to the rescue
We can solve this problem by adding the WCF RoutingService, a new .NET 4 feature, to the mix. In this case the client only talks to the routing service and the routing service is aware of each workflow service version and knows how to route the request to the correct address. This way the client never knows when new workflow services are created, all it knows about is the WCF RoutingService address.
So how does the WCF RoutingService where to send messages?
There are several ways this can be done but the easiest is to have the workflow service return a version number from the initial request that started the workflow. This version number is also a required argument for each subsequent request into the workflow. The WCF RoutingService can now use this version part of the message, or the lack thereof, to determine where to route the message. If there is no version information the message is always routed to the last version of the workflow service so new instance requests as well as WSDL requests are always send to the most recent version.
So does this solve all our problems?
Unfortunately not. This will solve the problem of updating the workflow service definition and keeping the different versions apart it does keep the workflow already running with their old definition. And that might be exactly what you want in some cases but if there is a bug in the existing definition you still can’t fix that. And that is a problem that can’t really be solved properly with WF4. This feature has been promised at the 2010 PDC for the next version of .NET but that doesn’t help us now.
Enjoy!
www.TheProblemSolver.nl
Wiki.WindowsWorkflowFoundation.eu
A couple of weeks ago, I had to create a custom EDI party trough code.
I noticed that the information provided on this topic was rather small and that other people were experiencing the same problem as well.
After some research I did on this topic, I discovered it’s actually rather easy to do these kinds of modifications through code.
Below you can find an example on how to create and modify your EDI Party.
You will need to add references to following assemblies in order to create and modify an EDI Party trough code.
These assemblies can be found in the BizTalk installation folder.
The first step is to add a new party to your BizTalk Group.
Below is an example how to add it through code, but it’s perfectly possible to add this through the BizTalk Administration Console.
The party you just created will be used to create a new partner.
After that you can tweak and modify every setting needed for your Party/Partner.
There are tons of possibilities to adjust, but below you can see some basic modifications I did.
When we open the BizTalk Administration console, we can view the result.
The source code of my example can be found here.
EDIPartyManagement.zip (18.43 kb)
Glenn Colpaert, CODit
I deal quite a lot with AS2 and BizTalk. I sometimes lose track of the different types of files when dealing with the certificates. I found a nice description of all the file types and a nice little converter online.
Here is the good description:
PEM Format
The PEM format is the most common format that Certificate Authorities issue certificates in. PEM certificates usually have extentions such as .pem, .crt, .cer, and .key. They are Base64 encoded ASCII files and contain “—–BEGIN CERTIFICATE—–” and “—–END CERTIFICATE—–” statements. Server certificates, intermediate certificates, and private keys can all be put into the PEM format.
Apache and other similar servers use PEM format certificates. Several PEM certificates, and even the private key, can be included in one file, one below the other, but most platforms, such as Apache, expect the certificates and private key to be in separate files.
DER Format
The DER format is simply a binary form of a certificate instead of the ASCII PEM format. It sometimes has a file extension of .der but it often has a file extension of .cer so the only way to tell the difference between a DER .cer file and a PEM .cer file is to open it in a text editor and look for the BEGIN/END statements. All types of certificates and private keys can be encoded in DER format. DER is typically used with Java platforms. The SSL Converter can only convert certificates to DER format. If you need to convert a private key to DER, please use the OpenSSL commands on this page.
PKCS#7/P7B Format
The PKCS#7 or P7B format is usually stored in Base64 ASCII format and has a file extention of .p7b or .p7c. P7B certificates contain “—–BEGIN PKCS7—–” and “—–END PKCS7—–” statements. A P7B file only contains certificates and chain certificates, not the private key. Several platforms support P7B files including Microsoft Windows and Java Tomcat.
PKCS#12/PFX Format
The PKCS#12 or PFX format is a binary format for storing the server certificate, any intermediate certificates, and the private key in one encryptable file. PFX files usually have extensions such as .pfx and .p12. PFX files are typically used on Windows machines to import and export certificates and private keys.
When converting a PFX file to PEM format, OpenSSL will put all the certificates and the private key into a single file. You will need to open the file in a text editor and copy each certificate and private key (including the BEGIN/END statments) to its own individual text file and save them as certificate.cer, CACert.cer, and privateKey.key respectively.
OpenSSL Commands to Convert SSL Certificates on Your Machine
It is highly recommended that you convert to and from .pfx files on your own machine using OpenSSL so you can keep the private key there. Use the following OpenSSL commands to convert SSL certificate to different formats on your own machine:
OpenSSL Convert PEM
Convert PEM to DER
openssl x509 -outform der -in certificate.pem -out certificate.der
Convert PEM to P7B
openssl crl2pkcs7 -nocrl -certfile certificate.cer -out certificate.p7b -certfile CACert.cer
Convert PEM to PFX
openssl pkcs12 -export -out certificate.pfx -inkey privateKey.key -in certificate.crt -certfile CACert.crt
OpenSSL Convert DER
Convert DER to PEM
openssl x509 -inform der -in certificate.cer -out certificate.pem
OpenSSL Convert P7B
Convert P7B to PEM
openssl pkcs7 -print_certs -in certificate.p7b -out certificate.cer
Convert P7B to PFX
openssl pkcs7 -print_certs -in certificate.p7b -out certificate.cer
openssl pkcs12 -export -in certificate.cer -inkey privateKey.key -out certificate.pfx -certfile CACert.cer
OpenSSL Convert PFX
Convert PFX to PEM
openssl pkcs12 -in certificate.pfx -out certificate.cer -nodes
Here is their little certificate converter: