Does biztalk have Service Packs? Or just Cumulative updates?
I am unable to see any service packs after 2009
BizTalk only has cumulative updates, they do not have concept of Service Packs, I believe they changed the model somewhere in 2006. You should look for latest cumulative updates.
Here is the full list
http://support.microsoft.com/kb/2555976
The BizTalk Server Product Group only ships Cumulative Updates. However, they mostly follow the Service Pack paradigm as a CU will contain all fixes from all previous CU's.
Related
Currently I am running Axon Framework and using Postgresql as the event store. I am investigating how to scale this horizontally but adding nodes via the k8s HPA functionality regularly results in errors
org.axonframework.modelling.command.ConcurrencyException: An event for aggregate [x] at sequence [y] was already inserted
I was reading that Axon Server enables this type of scaling but I cannot find anything on migrating the current event store to Axon Server. Is this possible?
Well it seems my google skills are lacking. Found the process here:
https://docs.axoniq.io/reference-guide/axon-server/migration/non-axon-server-to-axon-server
This only covers migration to Axon Server EE though so I will have to dig more I guess.
We are currently monitoring a web API using the data in the Performance page of Application Insights, to give us the number of requests received per operation.
The architecture of our API solution is to use APIM as the frontend and an App Service as the backend. Both instances have App Insights enabled, and we don't see a reasonable correlation between the number of requests to APIM and the requests to the App Service. Also, this is most noticeable only in a couple of operations.
For example,
Apim-GetUsers operation has a count of 60,000 requests per day (APIM's AI instance)
APIM App Insights Performance Page
AS-GetUsers operation has a count of 3,000,000 requests per day (App Service's AI instance)
App Service App Insights Performance Page
Apim-GetUsers routes the request to AS-GetUsers and Apim-GetUsers is the only operation that can call AS-GetUsers.
Given this, I would expect to see ~60,000 requests on the App Service's AI performance page for that operation, instead we see that huge number.
I looked into this issue a little bit and found out about sampling and that some App Insights features use the itemCount property to find the exact number of requests. In summary,
Is my expectation correct, and if so what could cause this? Also, would disabling adaptive sampling and using a fixed sampling rate give me the expected result?
Is my expectation wrong, and if so, what is a good way to get the expected result? Should I not use the Performance page for that metric?
Haven't tried a whole lot yet as I don't have access to play with the settings until I can find a viable solution, but I looked into sampling and itemCount property as mentioned above. APIM sampling is set to 100%.
I ran a query in Log Analytics on the requests table and when I just used the requests count, I got a number that was closer to the one I see in APIM, but when I use a sum of the itemCount, as suggested by some MS docs, I get that huge number as seen in the performance page.
List of NuGet packages and version that you are using:
Microsoft.Extensions.Logging.ApplicationInsights 2.14.0
Microsoft.ApplicationInsights.AspNetCore 2.14.0
Runtime version (e.g. net461, net48, netcoreapp2.1, netcoreapp3.1, etc. You can find this information from the *.csproj file):
netcoreapp3.1
Hosting environment (e.g. Azure Web App, App Service on Linux, Windows, Ubuntu, etc.):
App Service on Windows
Edit 1: Picture of operation_Id and itemCount
Need to make a tool to search XML data from BizTalk messagebox.
How do I search all XML data related to lets say a common node called Employee ID from all data stored in the BizTalk MessageBox?
The BizTalk Message Box (BizTalkMsgBoxDb database) is a transient store for messages as they pass through BizTalk. Once a message has finished processing, it will be removed from the Message Box.
You probably want to research Business Activity Monitoring (BAM) which will allow you to capture message data as messages flow through BizTalk; message data can be exposed through its generic web-based portal. BAM is a big product in its own right and I would suggest that you invest time in researching all of the available features to find the one that suits your particular scenario. There are many, many resources available, however you might start by taking look at Business Activity Monitoring. There is also a very good book specifically on BAM: Pro BAM in BizTalk Server 2009
Alternatively, take a look at using the built-in BizTalk Administration Console tools for querying the Tracking database (BizTalkDTADb) which will hold messages for later reference based on your pre-defined configuration options. See Using BizTalk Document Tracking.
Finally, you could consider rolling your own message tracking solution, writing message contents to a SQL Database table, as messages are received in a pipeline for example.
Check out the BizTalk Message Decompressor on CodePlex! I've been using this tool for a couple of years with excellent results. Since you're hitting the messagebox directly, you should be very careful and be very familiar with the queries that you choose to execute.
As noted by a previous poster's answer, BAM and the integrated HAT queries in the admin console are the official, safest, and Microsoft prescribed answers.
"What makes a good BizTalk project" is a question I was asked recently by a client's head of IT. It's rather open ended, so rephrasing it slightly to :
"what are you top ten best practices for a BizTalk 2006 and onwards projects - not limited to just technical practices, eg organisational"
I wrote an article called "Top 10 BizTalk Server Mistakes" that covers some key best practices in terms is usable information rather than a simple list. Here's the listing:
Using orchestrations for everything
Writing custom code instead of using existing adapters
Using non-serializable types and wrapping them inside an atomic transaction
Mixing transaction types
Relying on Public schemas for private processing
Using XmlDocument in a pipeline
Using ‘specify now' binding
Using BizTalk for ETL
Dumping debug/intermediate results to support debugging
Propagating the myth that BizTalk is slow
...and the link to the complete article: [Top 10 BizTalk Server Mistakes] (http://artofbabel.com/columns/top-x/49-top-10-biztalk-server-mistakes.html)
The key point is to emphasize to the client that BizTalk is a swiss army knife for interop... an expensive swiss army knife. A programmer can wire up two enterprise systems with a WCF application as fast as you can with BizTalk. The key things to include/require when using BizTalk is to:
Have more than simple point integrations. If this is all you have, fine, see the rest.
Have all or a portion if a process that is valuable going theough BizTalk so that you can instrument it with BAM and provide process monitoring to the organization... maybe even some BI.
If you are implementing a one to many or many to one scenario, use of the BizTalk ESB patterns will pay deividends in th elong run
When there are items that need to be regularly tweaked - threshholds, URI'ss, etc... use of the Business Rules Engine can provide an easily maintainable solution.
When endpoints might be semi connected, BizTalk bakes in queueing of messages for no extra effort.
Complicated correlations or ordering of messages.
Integrating with exisitng enterprise systems can be simplified with the adapter packs provided as part of BizTalk. This alone can save big bucks. Asking Oracle, PeopleSoft or Siebel folks about XML and Web Services can be a challenging experience. The adapters get you and BizTalk through the enterprise apps' front door and reduces the work for themsignifcantly.
There are more I just can't think of at midnight.
Any of these items make BizTalk a winning candidate because so much of it is given to you with the platform. If you are not being required to provide any of these, you should really attempt to deliver some of these beneftis in highly visible way to the client. if you don't it's just an expensive and under utilized swiss army knife.
I'll start with Environment and Deployment Planning. Especially testing deployment and matching your QA/Stage (whatever the pre-production environment is) to the production environment so you don't find out some weirdness at midnight when you are trying to go live.
Very simple question, is there any cloud server enviroments avaliable these days for us .NET guys that rivals Amazons ec2?
EDIT:
PDC 2008 looks like there are some very interesting info, and only 4 days 2 hours to wait :-). Looks like I need to get saving fast for the conference fee though.
Hold your breath for PDC 2008 and you'll see. Also Amazon's EC2 service support for Windows images is in Beta. AWS Windows Support Blog Post
Oct 23 Update : AWS Windows Support Released To Production (details here)
Oct 27th Update : So you held your breath and saw the Reddog folk become "Windows Azure" cloud services and Sitka - SQL Server Data Services. Lots of activity to read and learn at MSDN, MS PDC site, Channel 9 etc. Have fun!
I use Mosso, a subsidiary of Rackspace. I've been pleased with them.
You can run PHP, Perl, .NET, and RoR on their system. MySQL as well as SQL Server.
http://www.mosso.com
Check out Sql Server Data Services and make sure to tune in to PDC 2008 next week.
It's not public yet but EasyDb is very .net-focused, it wraps your tables into an ASMX web service. There was a dnrtv episode on it, http://www.dnrtv.com/default.aspx?showNum=121
We took Mosso for a trial run earlier this year, and it was disastrous. On a number of criteria - uptime, customer service, flexibility - we would have been better off a $6/month shared hosting account. And they changed their pricing model midstream from a per-request model to a per-"compute cycle" model, the "compute cycle" being a mysterious proprietary metric that's impossible to optimize for because you don't know how it's calculated - the end result being that you could suddenly find yourself on the hook for thousands of dollars in charges for no good reason.