I have a client running a 1/2 dozen or so orchestrations running on Biztalk 2004 (that I wrote) that they use to exchange cXML documents (mostly too send orders) with their suppliers. It has a ASP.NET 1.1 front end. It uses the SQL adapter to store the parsed cXML. I gets & sends the documents via HTTPS.
My question: Is the upgrade to Biztalk 2006 R2 as straight forward as MS says? Any advice or things I should watch out for?
We finished a similar upgrade last year with little effort other than importing the projects into Visual Studio 2005. The upgrades were without issue. The biggest problem we had was with the various deployment scripts we used. There was a bit of rewriting to work with some of the new features of 2006. We also had to adjust to the multiple-host model for our apps. But all in all, no problems - just more features and API changes on deployment.
Best of luck.
At some point you will want to review the recommended tuning parameters for BizTalk 2006 R2 - I've prepared a list that may be helpful of the relevant resource links
http://intltechventures.blogspot.com/2008/11/2008-11-01-saturday-biztalk-2006-r2.html
Related
I was wondering what would be the correct deployment workflow for customization under AX 2009. For AX 2012 I found a nice whitepaper Deploying Customizations Across Microsoft Dynamics AX 2012 Environments .
But this doesn't help much because with AX 2009 there is no concept of model store deployment (unless I'm mistaken).
Are XPOs the way to go with AX 2009? If someone could point me in the right direction this would be great.
XPOs can and do work, but there are some issues using them. From most of what I've researched, when it comes to SOX compliance the best way to migrate code changes is by moving the binary server files - the .aod, .ahd, etc files - that are stored in the application directory of the server. Since these files are the compiled versions of the application code, it is easier to prove that the modifications that were created in a development environment are the same modifications deployed to the production environment. XPOs are plain text and can be manipulated in a text editor, making it more difficult to prove this, though not impossible.
I actually did a writeup of what we have done to manage our code deployments if you are interested. It covers XPO vs Layer file migrations, and ultimately describes our process for automated builds and deployments. Since we put it in place our auditors have been very happy when it comes to auditing our system.
I hope this question isn't too obtuse; however, I couldn't find anything specific. I'm a web-developer and I have an MSDN Subscription that gives me access to any SQL server edition I want. As a developer, I would like to know what I should choose to install on a dev machine based on this criteria (which other developers may relate to):
I need access to all the tools for SQL and T-SQL programming (I think all editions come with this?)
I want it to be efficient--I don't want it to take up too much ram\cpu processing time. My queries will not be very heavy so I'd rather trade off longer queries than to have the server taking up valuable resources.
I am programming for an enterprise sql version hosted somwhere else, but I don't need more than 1 Gigs of space, 1 CPU core support,
I never really worked with reporting tools, but would as a developer (Aka, non-DBA) would I ever need them on a dev machine?
Best integration with VS2013
I know that the SQL Server Developer edition is basically Enterprise, but without the liscence to use it for non-dev purposes. Based on the above criteria is there any sense for me to install it? Or should I choose SQL Express with Advanced Services? Perhaps Web?
Thanks for all your help,
All editions come with all the tools (unless you get into the BI side of things, then I think Express won't come with all of those tools).
In general, the edition won't make your local development environment any different in terms of resource usage. There are a few things that Enterprise / Developer have (like online index rebuild, certain optimizations etc.) that can make some operations more efficient, but these are highly unlikely to impact your day-to-day work or really change the number of resources SQL Server uses (these are very easy to cap through configuration anyway, e.g. if you don't want SQL Server to use more than x GB of memory, you can set that).
If you don't need more than 1 GB / 1 CPU in the ultimate deployment, you should probably develop on Express. This will prevent you from using Enterprise features inadvertently (which can happen if you use Developer). The down-side is that if you later do need features that aren't in Express (say you have another project where you will be deploying to Enterprise), you'll need to add an instance (with or without removing the old one). Given that you have access to MSDN, maybe the best solution is to install two instances - one Express, and one Developer, and then you can target the edition you want by using the appropriate instance locally.
I think that Express with Advanced Services come with these things, but I'm not an SSRS guy, so I'm not sure.
No single aspect of integration with Visual Studio should be edition-dependent.
Also, Web is not an edition that is suitable for your workstation - try to find a license somewhere. This edition is exclusively for web hosts and resellers who offer SQL Server as part of their hosted offerings.
We are supposed to benchmark the performance of a dynamics ax 2012 application.
I have no prior experience in dynamics ax 2012 or load testing of desktop applications.
If anyone has worked on the same, please tell me the best available options.
From what I have been reading, I've gathered there is nothing like Application Benchmark Toolkit(which was for ax 2009) for ax 2012.
Currently Microsoft has released some benchmarking white papers, specifically the 'Microsoft Dynamics AX 2012 Day in the Life Benchmark' which gives some guidance on the sizing of environments. If you want to do your own load testing there is no easy way to get there currently. The closest you could reasonably get would be:
Writing a number of routines or jobs either in X++ or C# that call AX services and perform operations. This would let you do things like enter a large number of customers and orders and time the operations. This does not benchmark the client performance though.
Visual Studio 2010 Ultimate has UI automation testing tools that allow you to attach to an application and create UI tests that perform certain actions. You could use this to do manual tests in the Dynamics AX Client and then run them multiple times. Obviously this is only ideal if you need to test client performance.
According to recent posts from Convergence 2013, Microsoft is supposed to be releasing a load testing tool that seemingly meets your requirements in April/May 2013, so you may in fact luck out from a timing perspective unless you have a very tight implementation deadline.
A few quick rules of thumb from a performance perspective:
Don't virtualize SQL Server, Microsoft says best case scenario (You have a really good SQL Admin), you'll take a 15% performance hit, and worse case it's closer to 60%.
Use dedicated AOS's to handle things like batch jobs since they tend to get more and more involved as the system gets more mature.
I'll reply to an old question, maybe it'll help some people in the future who land here through google.
In the meantime there is an application benchmark SDK for dynamics AX 2012.
You can find full documentation here.
Basically it's a set of tests you run from visual studio, there are some standard tests available and the SDK allows you to perform your own tests
A development shop has a range of ASP.NET projects using SQL Server 2000, 2005, 2008. 2008 R2 databases.
How would you design, develop, maintain, version control, fill with test data, stress load, test, automate, maintain in sync with production such range of databases?
Does recent Visual Studio 2010 Ultimate or Database Eds support SQL Server 2000 databases?
Update: The question is not confined to VS2010 or even to MS-only products.
Even if confined, then how to organize the development infrastucture and environment.
Also, variants of cutting some of the functionalities in order to minimize/cut or optimize time and expenses are to be considered.
I was reading so far on it (with sublinks and related links):
Different Development environment than Test & Production environments?
Keeping testing and production server environments clean, in sync, and consistent
How to keep track of performance testing
Get Your Database Under Version Control
http://www.codinghorror.com/blog/2008/02/get-your-database-under-version-control.html
Verify database changes (version-control)
Is Your Database Under Version Control?
http://www.codinghorror.com/blog/2006/12/is-your-database-under-version-control.html
How do you stress load dev database (server) locally?
I suggest you develop against the lowest common denominator (i.e. the SQL 2000 database).
You can then backup and restore this database to the other version of SQL Server in your testing and staging environments to give you the range of database servers you need.
First have your developers load client tools of all three versions on their machines. You have to start from 2000 and work out to work correctly. Then have them work in Query Analyzer for projects supporting 2000 and in SSMS for projects supporting 2005 or 2008. Insist that they always work only against the lowest version of the database the client will be using. Most things that work in 2000 will work in 2008 (not so true of the next version, so customers on 2000 should strongly be encouraged to upgrade.)
Have them do all work in scripts (even database changes and inserts to lookup type tables) and check the scripts into source control just like any other code.
If you have testers, make sure they are connected to the correct version of the database and that they do tests against that and not some higher version.
I also would have a cheat sheet made up for your developers concerning what T-SQL code will work on which version. Best way to do this is to look in Books Online for 2005 and 2008 to see what new features were added.
But it is critical that they only work in the database the particular project will support or you will have to rewrite large swaths of code when it goes to prod. Newer devs don't know 2000 and are used to using things like CTEs that are not supported. It is best they find out immediately when they write the code that it won't work not in test or worse on prod.
We own a small company and develop asp.net websites. Here is our work procedure:
We have a server at the company with Sql Server 2008 and IIS 7.5 installed on it. All our projects including the database and website pages are on the server. We connect to the server and edit the files using FTP, so any change to a web page can be seen at once. The programmers (less than 10 programmers) connect to the server using Visual Studio 2010.
Now we want to include source control system in our work. The problem is including a SCM in our work requires changing our way of working.
Does anyone have any advise on setting up the working environment?
Thanks in advance.
You first need to decide on what type of SCM you are going to use - centralized or distributed.
One centralized SCM is TFS - this is from MS and integrates very will with VS. I believe there is an express (basic) version that is free, but the other editions are quite expensive.
An easy and free centralized SCM to start with is subversion - you can install the SVN server on your server and setup a client for each developer.
A distributed SCM does not have a server - a popular one is GIT.
Do read up on all of these before deciding. You will also have to figure out a good workflow for your team. Start with a small project so you can gain understanding and minimize the cost of mistakes.
So many ways to do this :)
One way is to use something like http://beanstalkapp.com/ to store your source code under SVN. Each developer then has a local copy of the code to work on and a good history of changes is kept when developers commit their code (at least daily), and these changes can be emailed around to the team if you want them to be. One member of the team is then tasked with uploading the latest SVN code to the testing server once it's tested and approved locally (probably at the end of each day).
I'd recommend your developers install http://www.visualsvn.com/visualsvn/ Toolbar into Visual Studio if you use SVN.
As an alternative to hosting your SVN repository with someone like Beanstalk, you could use the free http://www.visualsvn.com/server/ which cuts out the need to upload the latest code to your testing server, as it'd be stored right there and updated on each SVN commit. But this adds an overhead in terms of backups etc.
Let us know what road you go down in the end.