i am trying to develop an SSIS package with web service task, i have specified the service url
http://localhost/myservice.asmx?wsdl in the connection manager and configured the location of wsdl using expressions
but when i deploy the package to a prod environment, SSIS package will be on a DB server and web service will be hosted on a different server, which means i need to change the service url in the dtsConfig file.
but the problem i am facing is when i change the connection string url in dtsConfif file it will not update the wsdl file, and it points to old url and package fails with 404 error
If I understand, you are changing a value in the dtsConfig, but your SSIS package is not picking up on the new value. Are you sure it is looking at the updated dtsConfig file when it runs?
You should have, for example, a SQL Server Agent Job that is executing your SSSI package, and it should be pointing to the updated configuration file; or else, the Job should override the configured values. You can try different ways to set the url string to the desired destination.
Related
I have a .NetCore stateless WebAPI service running inside Service Fabric local cluster.
return Endpoint.Start(endpointConfiguration).GetAwaiter().GetResult();
When I'm trying to start NServiceBus endpoint, I'm getting this exception :
Access to the path 'C:\SfDevCluster\Data_App_Node_0\AppType_App10\App.APIPkg.Code.1.0.0.diagnostics' is denied.
How can it be solved ? VS is running under administrator.
The issue you are having is because the folder you are trying to write to is not supposed to be written by your application.
The package folder is used to store you application binaries and can be recreated dynamically whenever an application is hosted in the node.
Also, the binaries are reused by multiple service instances running on same node, so it might compete to use the files by different instances.
You should instead instruct your application to write to the WorkFolder,
public Stateless1(StatelessServiceContext context): base(context)
{
string workdir = context.CodePackageActivationContext.WorkDirectory;
}
The code above will give you a path like this:
'C:\SfDevCluster\Data_App_Node_0\AppType_App10\App.APIPkg.Code.1.0.0.diagnostics\work'
This folder is dynamic, will change depending on the node or instance of your application is running, when created, your application should already have permission to write to it.
For more info, see:
how-do-i-get-files-into-the-work-directory-of-a-stateless-service?forum=AzureServiceFabric
Open folder properties Security tab
Select ServiceFabricAllowedUsers
Add Write permission
Is there any way for the AzureReader2 plugin to read its connection string and endpoint config values from the service config file rather than just the web.config?
The problem is that we build Azure package files (.cspkg) and web.config files are embedded within the package. Therefore we strive to keep our web.config files constant across all different deployments (test, dev, and production). We normally deploy using a package file and a service config file.
Install AzureReader 2 via code during application startup instead, and you can pass it the connection string directly:
var nvc = new NameValueCollection();
nvc["endpoint"] = "http://127.0.0.1:10000/devstoreaccount1/";
nvc["connectionString"] = "UseDevelopmentStorage=true";
new AzureReader2Plugin(nvc).Install(Config.Current);
I created a SSIS Custom Log Provider (SQL Server 2012 / Visual Studio 2010 / .Net Framerowk 4), and now I have to call a WCF service. I am not sure how to do that, since this is a custom library project, with no config file.
Ideas? Thanks!
This is a tricky thing to do in SSIS. You would be better off calling the WCF Service from C# and using that app to populate and thus stage a table that you can get to from SSIS.
Having said this...if you want to access a WCF Service here are the basic steps.
WCF Endpoint Config Settings. The endpoint to your WCF Serivce must be placed in the dtsexec.exe.config AND the DtsDebugHost.exe.config file located in the following folder: C:\Program Files (x86)\Microsoft SQL Server\100\DTS\Binn it would be wise to do the same in the Program Files folder if you are running 64 bit SQL Server as well.
Now you can create your SSISScript and add the Service Reference by right clicking on References and then Add Service.
If you have complied your own "internal" Proxies and contracts into DLL then you will need to copy those to the same location as the dtsexec.exe above AS WELL AS registering them in the GAC.
Remember...you need to do this where the SSIS package will run so typically your local instance of SSIS and the Production SQL Server.
Now...an alternative to this may be to "Brute Force" code all of the WCF Endpoint settings in code in your SSIS Script. I have not tired this but if it works that would eliminate the need for the endpoint in those obscure locations and config files. It would be cleaner and a better route. You could then store your WCF endpoints and other settings as variables the pass them into the SSIS Script as readonly values.
Good Luck!
As a newbie to Enterprise Applications I'm trying to get it done.
I developed an Enterprise application in Netbeans 7.1.2. It runs successfully using the default Glassfish server. With the need to change the server, I downloaded and installed Tomee+ server, and made some changes to make Tomee Manager Interface work on my system.
I deployed the .ear file (Glassfish server output) into Tomee+ by placing it in the Tomee webapps folder, with the server in the running state. It gets automatically deployed and appears in the Tomcat Web Application Manager interface.
Then, by providing the suitable path in the address bar, like http://localhost:8080/app-war/faces/app.xhtml, it provides the frontend screen but the backend process is not working if I click the submit button. Instead, it simply provides a status page, like HTTP Status 500 - javax.el.ELException: javax.ejb.EJBTransactionRolledbackException: Transaction was rolled back, presumably because setRollbackOnly was called during a synchronization.
My question is: what went wrong with the steps I took for deploying it in Tomee+ server?
no more verbose stack?
btw can you try to:
1) check you have in tomee.xml the line
2) put your ear in /apps/ instead of webapps/
The point is by default (can be configured with the snapshot/next release) tomee extracts the ear in a folder simply removing the extension (webapps/your-ear/ for instance) and then tomcat takes this folder as a webapp so your deployment is no more the one expected. That's why moving it over a folder not managed by tomcat (apps) is often enough.
That's said, Glassfish transaction management is sometimes too tolerant (why i ask the full stack you got).
I'm using the web deploy API to deploy a web package (.zip file, created by MSDeploy.exe) to programmatically roll the package out to a server (we need to do some other things before we release the package which is why we're not doing it all in one go using MSDeploy.exe).
Here's the code I have. My question is really to clarify what is happening when this is executed. In the package parameters XML file I have the application name specified ("Default Web Site") but that's about it, there's no other params are specified in there. From testing the server it appears the package gets deployed successfully but my question is are any other settings on the server I'm deploying to getting changed without my knowledge, are any default settings published etc.? Things like security settings, directory browsing etc. that I might not be aware of? The code here seems to deploy the package but I'm anxious about using this on a production environment when I'm so unsure of how this API works. The MS documentation is not helpful (more like non-existant, actually).
DeploymentChangeSummary changes;
string packageToDeploy = "C:/MyPackageLocation.zip";
string packageParametersFile = "C:/MyPackageLocation.SetParameters.xml";
DeploymentBaseOptions destinationOptions = new DeploymentBaseOptions()
{
UserName = "MyUsername",
Password = "MyPassword",
ComputerName = "localhost"
};
using (DeploymentObject deploymentObject = DeploymentManager.CreateObject(DeploymentWellKnownProvider.Package,
packageToDeploy))
{
deploymentObject.SyncParameters.Load(packageParametersFile);
DeploymentSyncOptions syncOptions = new DeploymentSyncOptions();
syncOptions.WhatIf = false;
//Deploy the package to the server.
changes = deploymentObject.SyncTo(destinationOptions, syncOptions);
}
If anyone could clarify that this snippet should deploy a package to a web site application on a server, without changing any existing server settings (unless specified in the SetParameters.xml file) that would be really helpful. Any good resources on using the API or an explanation of how web deployment works behind the scenes would also be much appreciated!
The setparameters file just controls the value for the parameters defined in the package. A package might be doing much more than that. Web deploy has a concept of providers and any given package can have one or more providers.
If you want to make sure that the package is not changing server side settings the best approach you can take is to use the API but make the packages be deployed via Web Management Service. This will give you two benefits:
You can control what providers you allow through.
You can add users and give restricted permissions to them to deploy to their site or their folder etc.
The alternate approach is to:
In the package manually look at the archive.xml and look for the providers in the package. As long as you dont see any of the following providers that can cause server settings change such as apphostconfig or webserver or regkey (this is not a comprehensive list) you should be good. Runcommand is a provider that allows you to execute batch scripts or commands. While it is a good provider for admins themselves you need to consider whether you want to allow packages with such providers to run.
You can do the above mentioned inspection in code by calling getchildren on the deployment object you create out of the package and inspect the providers and the provider paths.