I'm currently migrating from BizTalk 2010 to BizTalk 2016. At the same time I'm also migrating from ClassRfc to NCo for the SAP adapter.
With the first RFC call that I make, I noticed that the decimal separator is a comma instead of a period.
I checked with some idocs I receive and there it is still the period as I would expect.
Has somebody experienced the same issue before?
It seems that the regional settings of your host instance account are used. Mine was set to the default "Dutch (Belgium)". Changing the decimal sign fixed the issue.
Related
I got the following error while setting up an EDI profile for a trading partner in BizTalk Server 2013.
Unable to cast object of type ‘Microsoft.BizTalk.Administration.EdiExt.ComboItem’ to type ‘System.String’. (Microsoft.BizTalk.Administration.EdiExt)
No matter what I do, it never goes away. What can I do to proceed?
For anyone who stumble upon this page in future, I found a workaround on this blog. The trick is to keep clicking APPLY button after every field change.
Apparently it seems a UI bug in the product which has been patched up by Microsoft till now. Microsoft has also provided a patch here for BizTalk Server.
Update: The patch from Microsoft is for BizTalk Server 2016.
I recently installed CU9 to BizTalk 2010. Microsoft site (https://support.microsoft.com/en-us/kb/3136004) claims that all previously CU are included in latest CU.
BizTalk Server uses a cumulative update (CU) model for providing fixes and updates. Each cumulative update includes new updates in addition to all the updates that were included in previous cumulative updates
Now I have problem with deployment ("Error saving map. Stored procedure returned non-zero result." error message when you deploy the BizTalk Server 2010 applications in BizTalk Server 2010 Administration Console") supposed to be fixed in CU4.(https://support.microsoft.com/en-us/kb/2667310)
So do I need to install all CUs from 1 - latest (for BizTalk 2010) to be fully upgraded?
You do not need to install all of them, the latest is just fine. They are cumulative as is stated.
That being said: have you tried uninstalling the latest CU (CU9) and installing CU4 instead? I assume you had no CU's installed before?
Unfortunately, lately Microsofts track records in relation to BizTalk CU's is not something to be proud of... There were quite a few issues with CU's already. It is not unthinkable that some CU after CU4 reintroduced the issue.
Also: the specific issue you are mentioning is something that was supposedly being fixed in CU4. However, this is just one particular case that was solved. There are still other remaining cases which have not been fixed yet.
Problem solved. It turned out that this App is using resources from another app that was not fully upgraded and one schema was missing in it. After deploying/upgrading that shared application everything went well.
I have been trying for a day now to enable various IIS services on a laptop.
Using Control Panel, Programs and Features, Turn Windows Features On and Off.
The key feature I am trying to enable is ASP.NET.
I get a stupid error message that gives no clue (An error has occurred. Not all of the features were successfully changed.), but the event log shows a whole string of errors, starting as below.
Unable to install counter strings because the
SYSTEM\CurrentControlSet\Services\ASP.NET_64_2.0.50727\Performance key
could not be opened or accessed. The first DWORD in the Data section
contains the Win32 error code. 020000000E0E0000
Installing the performance counter strings for service
ASP.NET_64_2.0.50727 (ASP.NET_64_2.0.50727) failed. The first DWORD in
the Data section contains the error code. 02000000C9120000
I have searched the net, and tried various remedies, all with no success.
These threads discuss the same topic, without solving it:
http://social.technet.microsoft.com/Forums/windows/en-US/d711ecd1-620c-473c-af39-e607bbe2ec18/turn-windows-features-on-or-off-application-development-features?forum=w7itproinstall
http://blogs.msdn.com/b/tom/archive/2008/04/11/asp-net-performance-counters-missing.aspx
I tried uninstalling all versions of ASP.NET using aspnet_regiis.exe -Ua on each and every version on Framework and Framework64, then adding them back. None of this has made any difference whatsoever.
Any ideas?
I had this problem too. I had 2 errors logged in the Windows Application Event Log:
Unable to install counter strings because the SYSTEM\CurrentControlSet\Services\ASP.NET_64\Performance key could not be opened or accessed
Installing the performance counter strings for service ASP.NET_64 (ASP.NET_64) failed. The first DWORD in the Data section contains the error code.
Note that these msgs are similar, but not the same as the original poster, probably due to different versions and time moving on. I'm on Windows 7 64-bit, with various .NET Frameworks installed, at least 3.5 and 4.x, plus some remnants at least of 2.x. I have Visual Studio 2010 Pro installed, and just installed VS 2013 Community this morning. I already had IIS installed, and I think it was installed before any VS versions. This is the first time I explicitly tried to enable ASP.NET under IIS on this machine.
If you look in the registry, it's true, this key does not exist: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\ASP.NET_64
I narrowed down the problem to the .NET Extensibility feature, on which the ASP.NET feature depends and automatically checks/enables (not that this helped me).
I followed the other answer in this thread: "Control Panel > Programs > Turn Windows features on or off, and switched off Internet Information Services (which will turn off all the subfeatures), then clicked OK. [Reboot as prompted.] Then I went back to the Control Panel and turned on all the IIS services I needed and the error did not resurface."
HOWEVER, be sure to enable the ASP.NET feature (which auto-checks/enables related dependent features such as the problematic .NET Extensibility feature) at the time you are re-enabling IIS. If you do it at the same time, the registry key is successfully re-added, if not then not. Doing it piecemeal didn't work for me and just resulted in the same error message. A reboot was not required for the enabling (just the disabling), but I have found that changes over time.
Note that there are other problems out there that generate errors when this feature is added to IIS. Apparently if IIS is installed before ASP.NET then the solution is the register ASP.NET with IIS. There are MS pages around that tell you how. (e.g. http://blogs.msdn.com/b/tom/archive/2008/04/11/asp-net-performance-counters-missing.aspx) Use the link to the ASP.NET IIS Registration Tool to fix that problem (although this disable and re-enable of IIS may also work).
I went through these other fixes and they didn't help me. At least one generated an error, but again probably because I had that ASP.NET_64 registry key missing. The standard Windows Fix tool didn't do anything for me either. Updating my .NET Framework to the latest (there happened to be an update to 4.5.2 or something similar) didn't help either.
My guess, in hindsight, is that maybe VS 2010 is too old, and is 32-bit on my 64-bit OS, and it resulted in problems with my registry keys. Maybe. I'm just guessing.
(I would have simply commented on the other answer/solution, but apparently I don't have sufficient points - this would seem to be a flaw in that design.)
I was having the same issue with Windows 7 Enterprise but this worked for me:
Control Panel > Programs > Turn Windows features on or off, and switched off Internet Information Services (which will turn off all the subfeatures), then clicked OK. Then I went back to the Control Panel and turned on all the IIS services I needed and the error did not resurface.
In some of our BizTalk 2009 development environments, when attempting to process a HIPPA X12 file, 4010 270 file type, any element defined in the schema to be type X12_AN is throwing an "Invalid character in data element" error; e.g. NM103__InformationReceiverLastOrOrganizationName. The invalid character that it is complaining about is the letter "U". It's only the capital letter "U" and not a lowercase "u".
This error only presents in our development environments that exist in Citrix VDIs running Windows Server 2003 R2 Enterprise X64 Edition. The instance of BizTalk Server 2009 installed on the VDIs has been updated with the most recent hotfix.
So far, I tried everything I can think of from converting the input file encoding, to retyping the entire file manually. I recompiled and deployed both the schemas and maps. I even enabling and disabling EDI validation at the party level. Nothing seems to be working.
Has anyone seen this type of error before? Is there any way to modify or override the character set that is used for element validation in BizTalk?
Any information that you can offer would be greatly appreciated!
It looks like you have a couple of different issues here. I can't speak to the differences (implied by your post) between your Dev and Production environments.
As to the rest:
Yes, you can modify the X12 Validation. I don't have it in front of me but I believe you can just turn it off completely (if that's what you want). Otherwise, you have to (essentially) create a custom 270 schema that allows the character (you can even do this to make elements that would otherwise be invalid valid), and then use that custom schema for any partner that hits that validation rule.
What I've always done is to modify the incoming file: send it through a regex that will change that character in that field to a lowercase 'u'. As long as you're keeping a copy of the original (unedited) message, and you're not changing any actual data values, you won't run into any HIPAA regs.
I would also encourage you to go through the offending files with the proverbial fine-toothed comb. Usually (not always) there is something else that is actually causing the error, but it only manifests noticeably in circumstance X (in your case, a capital U in your NM103).
Revisiting this issue after a couple of weeks I found the fix for this issue to be much simpler than expected.
We work in the the healthcare industry and are currently supporting HIPAA 4010 applications while actively upgrading those applications in our development environment to meet the HIPAA 5010 requirements. As such, this issue was caused in BizTalk when the party property "Use ISA11 as repetition separator" was CHECKED within the configuration of a party used only for 4010 development. Since the default ISA11 value for 4010 is "U", BizTalk reported that character as invalid everywhere it was found.
I hope this saves someone else a lot of headaches. It's fun to be reminded every now and then that you should always check the obvious, simple solutions first, even if you KNOW they're not the issue!
I'm having a real hard time with what seems to be a rather old bug (pre-2009) in the Windows Azure platform. In short, after deploying to Azure I get HTTP 404 responses for JavaScript resources loaded via WebResource.axd. This is a big deal since it breaks most of the AJAX functionality on the website. The interesting part is that things get normal about 2 hours after the deployment and the 404-ing resources start loading normally. And the event more interesting part is that the 404 errors don't occur after each deployment.
After a lot of Googling around I found a similar case on the Azure forums. Yi-Lun Luo's last post makes me think the problem in my case is related to the bug he describes. Maybe I'm wrong, but there seems to be a connection between the 2 hours it takes for the 404 errors to cease and the fact that my timezone is UTC +2.
Please, if anyone has had a similar problem or has an idea for a workaround, let me know. I would be really grateful!
We have run into this before on another project. It's actually not an Azure problem at all, but rather a bug in how the WebResource.axd is loading the assemblies (roughly speaking). The problem is related to the timezone. If the binaries you are building and deploying are in a timezone "ahead" of the timezone you are running the code in then you will run into the problem you are seeing. We specifically ran into the issue when dealing with a control from Telerik. We reached out to Telerik for help and they had some suggestions on thier site.
Basically, you need to "touch" the assemblies you build so that the last modified date is a time prior to the current time in UTC. The link uses this syntax (note commas are important):
copy /b <path to assembly which is built in the future>+,,
The build server was in the Eastern Time zone and the production servers were in the Central Time zone. We would copy the binaries to the production box and perform the command above on them. You could mimick this in Azure with a startup task and that should do the trick.