I am facing a problem in BizTalk 2006. The problem is that I have to reset ISA13 (Interchange control number).
Unfortunately I only have a BizTalk 2010 available here, so i'm not sure if this functionality is already present in BizTalk 2006/2006 R2.
In BizTalk 2010 and 2009 you have the option to reset the ISA on the following party agreement (see image below).
Do you have a similar option in BizTalk 2006 R2 in the party settings?
I also do not have BizTalk 2006/R2 installed.
My suggestion is looking for the related stored procedure, which in my BizTalk 2013 installation, it looks like the edi_ResetX12Icn in BizTalkMsgBoxDb.
Related
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.
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
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 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).
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