If you have to choose a Visual Studio 2005 edition to develop BizTalk 2006 in combination with Team Foundation Server, you should keep in mind that the Team Edition has all the features of the Professional Edition and some more (quoted from Microsoft):
- Team Foundation Server CAL includfor accessing Team Foundation Server
- Team Foundation Server Workgroup Edition included when purchasing Visual Studio Team System Editions with an MSDN Premium Subscription
- 64-Bit Debugging (IA64) enables you to debug 64-bit applications running on Windows 64-bit computers remotely
- Code Analysis Tools such as Code Analysis Check-in Policy (which enforces developers to run a code analysis before a check-in of code)
- Code Profiling Tools like Hot Path (that helps finding bottle necks inside the code) and a Stand-Alone Profiler
- Code Coverage to measure the effectiveness of tests on a line-by-line or even a block-by-block basis
- Item templates to run Performance tests
That means, that you can connect to the Team Foundation Server from Visual Studio if you just buy the CAL-licence which includes the Team Explorer. However, you won't get the benefits of the Team Edition then.
*I'm using the term "Team Edition" as a short form for the Development Edition of Visual Studio Team System 2008.
Random pitfalls (and their solutions) in EAI technologies such as BizTalk
Tuesday, January 27, 2009
Sunday, January 25, 2009
Managing hierarchical data in SQL Server 2008
There are roughly three different approaches to store and retrieve hierarchical data in SQL Server:
Parent-Child-Approach with Recursive TCE:
You can save the ID of a node's parent in an extra “parent column”:
Then you connect the referenced items with recursive Common Table Expressions (CTE).
HierarchyID data type:
Or you save the node’s hierarchy location with the new data type HierarchyID, which stores a path to a node and, thus, reveals the where in a tree the row occurs. A sample table looks like this:
The hierarchy is directly visible and, unlike in the simple parent-child-pattern, you have now the HierarchyID methods to work against the tree structure.
XML data type:
The third option is to represent the hierarchy in a XML document and store the instance in an xml column:
Doing this, you can retrieve information from the tree using XQuery.
This is meant to be a teaser... ;-) I'm going to write more about this the next days.
Parent-Child-Approach with Recursive TCE:
You can save the ID of a node's parent in an extra “parent column”:
Then you connect the referenced items with recursive Common Table Expressions (CTE).
HierarchyID data type:
Or you save the node’s hierarchy location with the new data type HierarchyID, which stores a path to a node and, thus, reveals the where in a tree the row occurs. A sample table looks like this:
The hierarchy is directly visible and, unlike in the simple parent-child-pattern, you have now the HierarchyID methods to work against the tree structure.
XML data type:
The third option is to represent the hierarchy in a XML document and store the instance in an xml column:
Doing this, you can retrieve information from the tree using XQuery.
This is meant to be a teaser... ;-) I'm going to write more about this the next days.
Tuesday, January 20, 2009
How does the SAP adapter retrieve the list of IDocs?
At a customer, we had the problem that the SAP adapter (building on SAP .net Connector v1.0.2) didn't retrieve the IDoc that we wanted to call:
To analyse how the SAP adapter retrieves this list of IDocs, we traced the RFC communication between SAP and BizTalk (transaction ST05*) and found out that the SAP .net Connector uses the BAPIs RFC_SYSTEM_INFO and IDOCTYPES_FOR_MESTYPE_READ to get a list of IDocs which are released:
Using transaction SE37, we (thanks, Rüdiger!) could analyse the BAPI IDOCTYPES_FOR_MESTYPE_READ and see that it uses the table EDIMSG to get the IDocs. And their we saw that the BAPI doesn't call for "message types" instead of "basic types". And, guess what, the message type had a different name then the basic type (which makes perfectly sense) and, thus, couldn't be found.
* Tipp: When logging to SAP to trace, you have to use the same user that you use inside the Send Port / Receive Location.
To analyse how the SAP adapter retrieves this list of IDocs, we traced the RFC communication between SAP and BizTalk (transaction ST05*) and found out that the SAP .net Connector uses the BAPIs RFC_SYSTEM_INFO and IDOCTYPES_FOR_MESTYPE_READ to get a list of IDocs which are released:
Using transaction SE37, we (thanks, Rüdiger!) could analyse the BAPI IDOCTYPES_FOR_MESTYPE_READ and see that it uses the table EDIMSG to get the IDocs. And their we saw that the BAPI doesn't call for "message types" instead of "basic types". And, guess what, the message type had a different name then the basic type (which makes perfectly sense) and, thus, couldn't be found.
* Tipp: When logging to SAP to trace, you have to use the same user that you use inside the Send Port / Receive Location.
Labels:
BAPI IDOCTYPES_FOR_MESTYPE_READ,
Biztalk,
SAP,
SAP .NET connector,
SE37
Monday, January 19, 2009
How to solve Problems when accessing an IDoc with the SAP Adapter
If you can't see an IDoc when you try to create a schema in Visual Studio using the SAP adapter (building on SAP .net connector 1.0.2), the problem is usually that the IDocs hasn't been published ("freigegeben"). You can check this here:
we60 - Check whether your IDoc is known in a specific SAP Release (we often had the problem that segments of an IDoc weren't known in a release)
we30 - You can check here whether all segements are published. Click on the segment, then "segment editor". There's a checkbox whether this segment is published.
we20 - If you can access the IDoc but can't send data to it, the IDoc might miss a partner agreement ("Partnervereinbarung").
we60 - Check whether your IDoc is known in a specific SAP Release (we often had the problem that segments of an IDoc weren't known in a release)
we30 - You can check here whether all segements are published. Click on the segment, then "segment editor". There's a checkbox whether this segment is published.
we20 - If you can access the IDoc but can't send data to it, the IDoc might miss a partner agreement ("Partnervereinbarung").
Labels:
Biztalk,
IDoc,
SAP .NET connector,
SAP adapter,
WE20,
WE30,
WE60
Friday, January 16, 2009
Creating Functoids inside the XML Code of the Mapping File
I had to create a BizTalk mapping with 246 Logical Existence-Functoids, which always checked whether a source field existed and then enabled or disabled the source field. You can save quite a lot of time (and I guess manual mistakes), if you use an text editor to create the XML manually to the transformation file (the format is called BTM and it's XML).
So, in case, your mapping looks like this, and you need many more functoids of that kind...
1) Open the transformation in some text editor.
2) Save the code of a new created functoid, for example:
<functoid functoidid="236" x-cell="59" y-cell="60" fid="317" name="Logical String" label=""><input-parameters></functoid>
3) Paste the code to a new file and put tabs into each line so that the code looks like this:
<functoid functoidid="[tab]236[tab]" x-cell="59" y-cell="[tab]60[tab]" fid="317" name="Logical String" label=""><input-parameters></functoid>
4) Now, copy the content to Excel and copy the lines so that the number, which should be pasted to extra columns, are increased-
5) Copy the content to a text editor, delete the tabs again and paste the code into the transformation file.
Ops! You should take care that the text editor that opens the BTM file externally doesn't change the unicode of the file.
So, in case, your mapping looks like this, and you need many more functoids of that kind...
1) Open the transformation in some text editor.
2) Save the code of a new created functoid, for example:
<functoid functoidid="236" x-cell="59" y-cell="60" fid="317" name="Logical String" label=""><input-parameters></functoid>
3) Paste the code to a new file and put tabs into each line so that the code looks like this:
<functoid functoidid="[tab]236[tab]" x-cell="59" y-cell="[tab]60[tab]" fid="317" name="Logical String" label=""><input-parameters></functoid>
4) Now, copy the content to Excel and copy the lines so that the number, which should be pasted to extra columns, are increased-
5) Copy the content to a text editor, delete the tabs again and paste the code into the transformation file.
Ops! You should take care that the text editor that opens the BTM file externally doesn't change the unicode of the file.
Subscribe to:
Posts (Atom)