Forum Replies Created
-
Posts
-
Guhan,
In your Orchestration (if you're using one), create a Send Port and configure it to "Specify Later". Once the app is deployed, configure the Send Port as an SQL port; this cannot be done on the development machine, the app has to be deployed. Click the configure button and you can enter your connection settings, etc.
What's the problem you are having? Is the XSLT generating any outbound records? Is it missing data. If you are going to ask for "urgent" help you need to be more specific 🙂
Depending on the inbound and outbound format you may or may not need a Looping Functoid, you may or may not have to connect the Script Functoid to anything; inbound or outbound.
Provide a sample of you inbound message format and outbound message format and I'll see what I can do.
The BizTalk Service has the following Dependencies:
- Enterprise Single Sign-On Service
- Event Log
- Remote Procedure Call (RPC)
Have you checked that these services are also set to automatic? Check the "Recovery" tab…what are the failure settings? What account do you have the BizTalk service set to run as?
Hope this helps!
The output of the Inline XSLT Call Template is an xsl:attribute, which when connected to the corresponding attribute in the outbound map, I do get a value now, but it's always 0. I know the XSLT works, because I have tested it. It seems as though my node references are not working….
You are getting the access violation on the Searcher.Get(), which is calling the WMI interrface to retrieve the data you need.
WMI has it own Access Control List, that is managed via Computer Management console
Open Computer Management
Open Services and Applications
Right click WMI Control -> PropertiesSelect Security tab
Expand root and select MicrosoftBiztalkServer
Click Security buttonAdd the user or group that runs the pipeline (??BizTalk Host Users and Biztalk Isolated Host Users) and give full permissions
I tried copying the code for resolving the Party Name, but I get the following exception at runtime: "Inner exception: Syntax error or access violation".
I've traced it to the line where it fails, but I don't know why it fails. It fails in GetMgmtDBConnectionString() on the line foreach (ManagementObject Group in searcher.Get())
Does anyone have any ideas as to why I get an access violation iterating through the collection?
When you generate the MSI deployment package, you get to choose which resources are included. So, you can ONLY include the changed dll.
As for bindings, I'd suggest exporting out the entire binding, opening up the XML file, and removing everything but the new receive port/location. Then in production, deploy the MSI, import the MSI (to get the orchestration changes to take effect), and then import the binding.
You may want to work with the BAM API instead of the TPE. TPE doesn't work well with repeating structures, so you might be better off controlling the BAM insertion yourself … http://blogs.msdn.com/richardbpi/archive/2006/03/29/564114.aspx
Database functoid will return the record set for a given row id. Using Table Extractors, you can get a specific column value for any column. For example, if you have 100 columns in the table and want to get the values for 10 columns, you will have to use 10 table extractor functoids. If you are planning to retrieve multiple rows in one DB lookup functoid, I don't think there is a way to do it. Anyway, there are some known issues with DB loopup functoid. It will not work properly if you use it for the situation where you are sending a bunch of messages at a time from the map. You better write your own script for this purpose.
See if you SQL Server Agent up and running. We had same problem which caused the performance issues. Since the SQL Server Agent was not running, none of the BizTalk CleanUp jobs are running. Once I started the SQL Server Agent, it cleared all the messages from spool and that resolved the performance problem.
I think it is more secure and configurable to place your configuration values in the Ent SSO. This way they are shared automatically across mutliple instances of the service.
check this http://geekswithblogs.net/toddu/archive/2004/10/08/12381.aspx for assistance on getting this working
Not that I am aware of. This is standard behavior for receive locations. They're shutdown by design after repeated failures. I would say your best bet is to use something like MOM to restart the locations after they shutdown.
Do you have other BizTalk applications running? if there was an error in the biztalk config file your whole bts environment would come crashing to a hault. If you got other applications still running then I don't think the problem relates to the biztalk config file.'
Could you post the exact error you are getting and perhaps a copy of your modified config file
