I recently started with the BAM from BizTalk.
I created a simple orchestration.
I configured the BAM for BizTalk ofcourse.
I used excel to create a simple schema with only textfields.
I deployed this xml schema to the BizTalk primary import using: bm deploy-all -DefinitionFile:myxml.xml.
Opened the TPE and opened the deployed schema.
Opened the orchestration and here opened the used schema and linked the schemafields to the bamschemafields.
After this I applied the tracking profile.
I then put a file through BizTalk which uses the orchestration. The file was outputted.
If I now check in the primary import database, I can see that the file is visible in the active messages. But the completed field is set to false. And it doesn't change. Also no data is filled in, only the ActivityID and LastModified, none of the columns which i specified myself are filled, and also RecordID = null.
What am I doing wrong?
I thought I did all the necessary steps, I know it's all still pretty basic but I need to get this to work if I want to do more, right?
Getting BAM to work can be tricky sometimes. First, did you restart your biztalk hosts after deploying everything? That could cause issues if you didn't.
Almost the first thing I do when I run into any issues with BAM is to turn on BAM tracing and either redirect it to a file or use DbgView to check for any errors BAM might be running into.
One of the crappy things about BAM is that it will fail silently sometimes, with the only information about the error being dump on the BAM tracing, so getting familiar with it is important.
Related
I have used Dynamics AX Traceparser on a number of occasions and usually without issues. This time however I can't seem to manage to generate and AX ETW trace that will show SQL in my TraceParser.
I can confirm it's not because I didn't load a server session, so it's not this question.
Things I have tried:
I looked in the traceparser database, there is not a single query in there
I did the whole run as administrator thing
I verified registry settings
I started tracing from both server config and client config.
I tried converting the .trc file to an xml file using tracerpt but the resulting xml doesn't make much sense.
I tried deactivating the DATAAREAIDLITERALS in SQLSYSTEMSETTINGS
Things that are different/uncommon about this environment
I can't install the client and traceparser on the AOS itself
AX Build 5.0.1600.2967 has been installed (incorporating the DATAAREAIDLITERALS change) because this customer has a lot of parameter sniffing issues.
Does anybody have an idea what could be the issue?
Has anyone tested traces on an AX with that specific patch (as I can imagine the query generation change could affect the trace .mof configuration)
If anyone can suggest me of a way to verify if the trace actually contains SQL information that would be of help too, because now I have no clue if the tracing fails or the importing.
I am using Visual Studio 2013 to manage a .sqlproj file containing our database schema. The schema has been deployed successfully dozens of times.
When attempting to publish to one specific target database, the "Creating publish preview" step appears to fail, but no error is given. The output from the preview includes some expected warnings:
The column {...} is being dropped, data loss could occur
If this deployment is executed, changes to {...} might introduce run-time errors in {...}
This deployment may encounter errors during execution because changes to {...} are blocked by {...}'s dependency in the target database
I have unchecked "Block incremental deployment if data loss might occur".
The Preview just stops, and no script is generated.
This happens when there exists a stored procedure (or view or constraint or other object) in the target database, that isn't included in your sqlproj, that references a table that would be altered by deploying your sqlproj. SSDT apparently can't determine whether the change is safe unless the referring thing is included in your sqlproj, and then it errs on the safe side by blocking the deployment.
Disabling the "Block incremental deployment if data loss might occur" option only relaxes the data-loss checks. There isn't a "Block incremental deployment if run-time errors might occur" option.
You have three options:
add whatever stored procedures, views, or whatever from the target database to your sqlproj
uncheck the "Verify Deployment" option in the ssdt publish options (this is dangerous unless you're aware of the other referring sprocs and know that they aren't going to break)
if you're certain that everything that should exist in the target database is contained in your sqlproj, you can enabled the "Drop objects in target but not in source" option
The issue may also be caused prepending a database object with the wrong schema. For instance a table being referenced within a stored procedure SQL statement and the table being prepended with an incorrect schema name.
Additionally, we had some permissions for a specific security group that once we removed the solution would build again. In order to troubleshoot the error perform a schema compare of the project code and the target database. Remove differences from the database until the publish functionality works. The last item that you removed from the database is your culprit.
The last warning pattern appears to be more than a warning:
This deployment may encounter errors during execution because changes
to {...} are blocked by {...}'s dependency in the target database
appears to have been the culprit behind stopping the rest of the preview and the generation of the script.
Interestingly, the schema change being introduced would not have broken the triggers referenced in the preview output.
removing schemabinding from the view allows the publish to succeed with only warnings
I have a legacy ASP application that I support. By support I mean that I haven't touched it since about 2005 because its just worked.
However there were a couple of data issues in the Access database that the ASP application uses. So like a fool I opened the database directly over a fileshare (using MS Access 2007), fixed the data and saved it down (in Access 2000 format).
Now the application will retrieve and display the data OK, but any updates fail with the error 3705: Operation is not allowed when the object is open. I have not changed the code in any way, the only change was the data update and database save.
I've found plenty of examples of this error, but they all relate to fairly simple issues like ensuring the recordset is closed before opening it, changing the CursorLocation enum, etc. I've tried most of these in the vain hope that something will work, but nothing has.
Any ideas how can I fix this?
Thanks.
UPDATE
I've installed a web based access database management system, and have tried to compact and repair the database. I received the error:
The Microsoft Jet database engine cannot open the file '<snip>'. It is
already opened exclusively by another user, or you need permission to view
its data. (-2147217911)
I have run the macro detailed here to determine who is logged onto the database, and just showed the admin user (which was me - while running it)
Those errors mean one thing: the database file is opened by some other process and thus is being locked.
Most likely that "web based access database management system" is the culprit, try to find how you can configure it to not lock the file, or get rid of it.
As a work around or way to verify the real problem, you can copy the .mdb file into different location and change the classic ASP connection string to check if you can update the database in its new location.
#Remou's comment above about checking the file and folder permissions was correct.
I had our server admin check the permissions, and it seems that the write access had dropped off the folder (and the files also inherit their permissions from the folder). He said that this has happened before when saving directly over the fileshare.
(accepting in lieu of an answer from #Remou)
Is there any way to recover the physical send & receive ports once deleted without exporting the bindings?
Even if you export the bindings the ports will not exist and so will not be exported. I think Bilal is correct - this data resides in the management database, so you would need to restore from a backup.
Your best option is always have a binding file configuration for your application. Once your BizTalk applications are configured with correct send, receive ports, orchestration host etc make sure you back up your binding configuration using "Export Binding" option in BizTalk admin console.
In fact, in bigger projects binding files will be normally owned by deployment teams for various environments and you never create ports using admin console in real environments.
It will be bit overkill to restore your BizTalk databases, just get your ports back. I would rather create them manually again, even if the numbers are hight. Restoring databases requires special attention, if you do it wrong you will end up reconfiguring the whole environment which will be time consuming.
I agree with Saravana.
My 5c: you can import existed binding files and that will not remove ports that are not in the binding files. The import process works in "addition" mode.
Is it possible in any way to edit an excel sheet through an ASP.net page that contains macro. I have tried to open the Excel sheet and it seems to just hang rather than load the excel. Testing on a page without macros works perfectly fine?
Disclaimer: I don't know the Excel license agreement and I don't know if utilizing Excel in a server process violates it or not. This is purely a technical description of how to get it working. The reader is advised to check the license agreement to see if it's allowed to do so or not. Different Office versions may have different license agreements. I used this method at several Fortune 100/500 companies and they didn't seem to care. Go figure.
This solution works but it has some limitations and require a fair amount of control over the server where it runs. The server also needs to have lots of memory.
To start, make sure that you perform a complete installation of every single Office feature on the server so that Excel won't try to install something if you attempt to use a feature that's not present.
You also need to create a dedicated user account on the server that has the right privileges. I can't tell you what exactly because in my case we controlled the server and we gave admin rights to this user.
When you have the user account, you need to log in as that user and run Excel (preferably all Office applications) at least once so that it can create its settings.
You also need to configure Excel to run under this user account when it's created as a COM object. For this, you need to go into DCOM Config on the server and configure Launch and Activation Permissions for the Excel.Application object to use your new user account. I'm not sure if I remember correctly, but I think after this step, running Excel as an interactive user was slightly problematic.
By default, Office applications try to display various messages on the screen: warnings, questions, etc. These must be turned off because when you utilize an Office application from a web application, it runs on the server so a human user won't be around to dismiss these messages - the Office program will just sit around indefinitely, waiting for the message to be dismissed.
You need to set (at the minimum) these properties:
DisplayAlerts = false
AskToUpdateLinks = false
AlertBeforeOverwriting = false
Interactive = false
Visible = false
FeatureInstall = 0 'msoFeatureInstallNone
to disable UI messages from Excel. If you use Excel 2010, there may be more, but I'm not familiar with that.
If you have Excel files with macros in them, you may have to disable macro security in Excel - that can't be done programmatically, for obvious reasons.
To access Excel services, implement a manager object that will actually hold the Excel reference - don't try to hold the Excel.Application object in the page because your page code will become very complicated and you may not be able to properly clean things up.
The object that holds the Excel reference may be a separate DLL or an out-of-process server. You must make sure, however, that when you acquire an instance of Excel on a given thread you always create a new Excel instance. The default is that an already running Excel instance will also serve other requests but that won't work for you because the same Excel instance cannot be shared among multiple threads. Each request-processing thread in IIS must have its own Excel instance - if you share instances, you'll have all kinds of problems. This means that your server will need to have quite a bit of memory to have many instances of Excel running. This was not an issue for me becasue we controlled the server.
If you can, try to create an out-of-proc (.exe) COM server because this way you can hold the Excel reference in a separate process. It's possible to get it working using an in-proc (.dll) COM object but it'll be more risky to your application pool - if Excel crashes, it'll crash your app pool as well.
When you have an .exe server, you can pass parameters in several possible ways:
Make your manager objet a COM object and pass parameters as properties.
Pass parameters as command-line parameteres to the .exe as it starts up.
Pass parameters in a text/binary file; pass the name of the file on the command-line.
I used all these and found the COM object option the cleanest.
In your manager object, follow these guidelines:
Wrap every single function that uses Excel in a try..catch block to capture any possible exception.
Always explicitly release all Excel objects by calling Marshal.ReleaseComObject() and then setting your variables to null as soon as you don't need them. Always release these objects in a finally block to make sure that a failed Excel method call won't result in a dangling COM object.
If you try to use any formatting features in Excel (page header, margins, etc.) you must have a printer installed and accessible to the user account that you use to run Excel. If you don't have an active printer (preferably attached to the server), formatting-related features may not work.
When an error happens, close the Excel instance that you're using. It's not likely that you can recover from Excel-related errors and the longer you keep the instance, the longer it uses resources.
When you quit Excel, make sure that you guard that code against recursive calls - if your exception handlers try to shut down Excel while your code is already in the process of shutting down Excel, you'll end up with a dead Excel instance.
Call GC.Collect() and GC.WaitForPendingFinalizers() right after calling the Application.Quit() method to make sure that the .NET Framework releases all Excel COM objects immediately.
Edit: John Saunders may have a point regarding the license agreement - I can't advise about that. The projects that I did using Word/Excel were all intranet applications at large clients and the requirement to use Word/Excel was a given.
The link he provided also has some tools that may be useful, although those libraries won't have full Excel functionality and if that's what you need, you don't have a choice. If you don't need full Excel functionality, check out those libraries - they may be much simpler to use.
A few links that may be useful to people trying to implement this approach:
StackOverflow question
Possible alternate products
COM server activation and window stations
The story changed a little while ago, with HPC Services for Excel.
With that, you can do Office Automation on a web server. I'm still trying to determine how it fits my situation, but you may want to check it out.