May not be the correct forum but do you guys have any news regarding the future of MS NAV and AX.
I have heard(from AX Veterans) that Microsoft will stop support of AX and NAV by 2020. They are going to replace it with Office 365 based new ERP.
If this question should not be here then I apologize in advance but I am worried about our future hence the question
This is the wrong forum, but I'll answer anyway.
AX is not going anywhere right now and if anyone says otherwise they're wrong. What you're probably hearing is Microsoft is ending support of the 2012 version in 2021...that's because they have a newer version out. It's equivalent to ending support of Windows 7 because we're on Windows 10 now.
These are the main active versions of AX in order (gotta love their naming conventions):
AX 4.0 (Support has ended)
AX 2009 (Support ends 2018)
AX 2012 (Support ends 2021)
Dynamics 365 for Operations
Dynamics 365 for Operations (aka D365fo aka D3fo) is the latest version and Microsoft is putting tons of weight and development into it. The core of it is still developed in X++. I also predict it will be the last version of AX and support will not end.
Dynamics NAV however I know very little on, but I believe NAV is being replaced with Dynamics 365 for Financials, which was formerly called "Project Madera", which was based on NAV. I could be wrong here and maybe D365 for Financial is the cloud version and NAV is the on-prem version. I don't know honestly.
Related
I see that IDMF was released today and it's supported for every 2012 version barring R3.
Is there another product that'll take it's place?
Is the development team still working on the R3 version?
According to the comments to the blog entry Microsoft Dynamics AX Intelligent Data Management Framework 2.0 released they are working on an update for R3 and plan to release it in mid September.
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
On a Tridion 2011 SP1 system, you have a choice between implementing SiteEdit 2009 SP3 and the more recent "User Interface update for SDL Tridion 2011 SP1" (also known as Experience Manager). What criteria are important in making this choice, and why?
For example:
Ease/cost of implementation
Infrastructure
License costs
Future support
Improved functionality
Both SiteEdit 2009 SP3 and Experience Manager are currently supported products. But it's clear that SDL's focus going forward is to further extend Experience Manager and not SiteEdit 2009 anymore.
In simple scenarios SiteEdit 2009 may be a bit easier to implement, due to the fact that Experience Manager has a bigger impact on the Content Delivery system due to the prerequisites for its Session Preview mechanism. When I install Experience Manager without Session Preview however, I find that it takes me no more time than setting up SiteEdit 2009 - a product that I've installed considerably more often.
But Experience Manager should typically cause fewer integration problems, due to the fact that it doesn't use a server-side proxy. A lot of more advanced authentication scenarios should simply work with Experience Manager, where they've proven challenging with SiteEdit 2009.
I think the above covers points 1 through 4 of your question. I'll leave number 5 to others, although I already mentioned "Session Preview" as one of the big new features in Experience Manager.
My thoughts (I'm still calling the new product UI btw):
UI will only work on 2011 Sp1 Hr1
SiteEdit is quite old now, UI is the later product... why would you choose to install something that isn't the latest software?
To your points:
the cost of installation of 2009 will be a waste when you have to installed UI shortly after :)
UI doesn't have the proxy anymore, it's part of the CM machine. setting up sites is much much easier
3/4. No idea on license cost, I'd imagine SE2009 isn't supported by SDL though, so I'd ask SDL.
UI is really great, I'm not going to write an essay on the new stuff, but I think the point on your list, that isn't there, should be:
'What do the end users think of both systems?'
This is a user editing tool, infrastructure, implementation of technical details, which I'm sure you can work around for either (should you have to), if you're putting in a tool that will be used by users and you have a choice to make, shouldn't it be the one that they agree works best?
I will add my 2 cents on costs - In a most of my implementations, getting SiteEdit 2009 installed and tested typically has taken less than half a day per environment. Make sure you apply all the hot fixes from SDL Tridion World to get it to work with the latest browsers.
The new UI can optionally use something called 'Session Preview' (to enable fast publishing) which makes use of several Content Delivery technologies such as OData. If you are not already using these in your implementation, then their is likely to be a considerable investment into infrastructure/application design to get it designed/installed/working/tested (I have heard cases where this has taken over a month), which will make the Experience Manager considerably more expensive to implement in the short term. If you don't use the 'Session Preview' feature, (as Frank has already said) the implementation time/cost is similar, but you will not benefit from the new fast publishing features of the newer product.
As for functionality - the two environments look and feel very different. Experience Manager is clearly the direction the products are moving towards and provides a much slicker interface. So if your client is new to SDL Tridion, I would suggest using it, however if they are a long time SDL Tridion customer who has experience with SiteEdit 1.3 or 2009, and you don't plan to take advantage of some of the newer features in the short term, I would be tempted to stay with SE 2009, and make the shift to Experience Manager when they upgrade to SDL Tridion 2013.
I was wondering if anyone could offer any insight as to when an update is going to be released for BizTalk to comply with the 5010A standard, all addendums and errata included.
I've just about exhausted myself with Google and Bing searches and the only thing that I can find is a very vague mention of first quarter 2011 on MSDN, but that timeline has nearly passed with no mention of it again. The BizTalk product team blog stopped blogging early last year and their last mention of 5010 was related to the first hotfix that was released for the original standard, but none of the addendums or errata are handled by that hotfix that I can see.
Maybe I'm missing something, but I'm up to my knees is 5010 development right now and we're getting close to testing across several transaction sets, none of which can be tested without the schemas being up to date.
Thanks in advance for your help!
Cumulative update package 2 for BizTalk Server 2009
* HIPAA 5010 Errata Schemas included
http://support.microsoft.com/kb/2497794
http://social.technet.microsoft.com/Forums/en-US/biztalkediandas2/thread/c61f2983-05f2-45fe-9d82-a10a25bd32f5
We are looking to turn an internal tool we have developed into a Visual Studio Package that we would sell to other developers. The tool will impact the custom editor and/or custom languages.
Visual Studio 2010 has redesigned the API's heavily to simplify much of the work involved for these types of integration but the key question we have is:
What is the typical adoption pace of new Visual Studio versions? Is there any information out there on adoption rates based on history? How many shops are still using 2005?
This will help us to consider whether to target just 2010 using the new APIs or whether trying to go back and support 2008 (maybe 2005) and testing it forward.
The short answer:
I'd primarily target VS2005 (as you shouldn't have much trouble getting a 2005-specific add-in to work in 2005/2008/2010 and thus will maximise your potential market).
The longer answer:
As you move from 2005 to 2008 to 2010, it gets progressively easier to write addins. In particular, the new extensibility features in 2010 make it much easier to build and deploy extensions (the older add-in and package systems used in 2005 & 2008 are much more painful to get working).
However, quite a large percentage of users still use 2005 (indeed, there are still a lot of people using 2003 and VS6), but I'd guess that most are now on 2008. Don't expect particularly high percentages of 2010 users until at least SP1, as a lot of companies won't even look at it until it's been out there for at least 6 months and any teething troubles are sorted out. So at present if you want a large market, I think you have no choice but to target 2005 and 2008.
As a general rule, if your add-in works in 2005 it is likely to work well in 2008 and 2010, so targeting the add-in at 2005 is the best bet if you want a large market. Unless there is a specific feature of 2008 that you need, then in most areas there is little difference between 2005 and 2008, so I'd advise you to start by targetting 2005 and only jump up to 2008 if you find a problem that can't easily be solved unless you use the 2008 APIs. This should work fine in 2010 as it's well supported, but there is no guarantee that future Visual Studios will continue to support add-ins.
The alternative, as you say, is to ditch the old "add in" interfaces and use the new 2010 extensibility APIs. This will make development easier, gain much more access to the internals of 2010, and be more future-proof... but it will take months/years for the market size to build.
Well, the larger the project, the more time it will take to move from 2005 to 2008 and 2010.
I know many projects that are still in 2005, so, if you can afford it - make a 2005 version, 2008 and 2010. Large project usually have funds to buy staff...
If you can afford only one version of the product, goto 2010, in the long term... this is the best option.
(2010 will start getting market share in a few days/week, If you can offer the product in less than 6 months, you should target the older versions first, as they will rule the market for at least one more year).