Service.Model calls within SSIS Script Task: "no endpoint element matching this contract could be found"
Tuesday, August 14, 2012 9:59 PM
I am using mssql2008 r2;bids vs2008 in an attempt to access a vendor's wcf service through a script task. Before moving to SSIS, I tested the methods I planned to use with a simple C# console client app. The core service is the same in both the SSIS script task and the test app. I changed the contract name in the app.config file to look like:
contract = "ST_namefoscript999zz99999999s9ss9blahblah22x.csproj.RemoteVendorService.IRemoveVendorService"
These bindings from this vendor also happen to be custom--so, manually assiging values as suggested in the link above for http bindings may not be the complete answer.
Is the service.model portion of the app.config file in SSIS/script task ignored?
Tuesday, August 14, 2012 10:04 PMModeratortry solution provided here to access WCF through SSIS:
Wednesday, August 15, 2012 12:51 PM
Thanks for responding. It looks like this walk-through in essence reitierates the link I found that resolved this same challenge I'm up against by manually setting the bindings within the script task program script.
For academic reasons, do you (or any other thread followers) know if it is because the app.config is not read in, or not interpreted for the service.model portion, or for another reason I don't know enough to ask about?
The reason I'm asking this question is because I've seen something similar when loading unit tests with wcf. In the case of unit testing, its because the unit tests are running in the test host processes app domain, so the app.config doesn't get loaded-- unless under the run settings, "Run Unit Tests in Application Domain" gets set to true.
- Edited by plditallo Wednesday, August 15, 2012 1:03 PM
Wednesday, August 15, 2012 1:18 PMModerator
There shouldn't be any difference running this code is a Script Task versa Console App. You can even run your console app from the package via execute process task.
I do not understand what made you think, or how did you detect the app.confog does not get applied? This is possible, for example when the path to app.config is not a full path, or when the account executing the package has no access to the directory where it resides.
Arthur My Blog
- Proposed As Answer by Eileen ZhaoMicrosoft Contingent Staff, Moderator Thursday, August 16, 2012 9:07 AM
Thursday, August 16, 2012 1:21 PM
Have you succeeded in running a wcf client to a remote vendor through an ssis script task? If you have, please let me know how you were able to get the endpoint visible to the script task. If I could get that to work so that I can utilize the contract definition inside the config file instead of programmatically forcing the custom bindings/endpoint, etc. within the script task, that would be ACES!!:-)
>>I do not understand what made you think, or how did you detect the app.confog does not get applied?<<
The  value for the endpoint collection shows as empty. If it had the contract value set from the app config file, or if I hadn't seen unit tests with the wrong app domain settings behave in the same way, I wouldn't wonder.
I'm open to suggestions. You mentioned something about not having a full path to app.config. Tell me what that means in context of an ssis script task.
Thursday, August 16, 2012 1:35 PMModerator
I have not used a WCF client before, but I did use a WebService call.
I trust the approach is similar.
Just craft the code in a .net console app 1st, have it working, then port to the Script Task. This is what I did with the WebServies.
The only difference would be in sourcing your variable(s) thru the package config versa app.config in the Console app. But then you just reference the needed package variables the standard way right within the Script Task.
Moral is: do not use the app.config in the Script Task, the way you apply a package config variable value is:
// Defined C# variable to reference SSIS user variable. DateTime LastLoggedUpdate = (DateTime)(Dts.Variables["LastUpdate"].Value);
Arthur My Blog
Thursday, August 16, 2012 1:53 PM
Hey , the reason that you get to see the error is the script task does not seem to understand the app.config or web.config. As Reza's link suggests you will be able to acheive what you want if you programatically configure the bindings and the endpoints.
Code the default settings for the binding information, and what you expect to change in the binding can be programmatically set through SSIS Variables to the script component, for e.g the _ServiceURL in the below code is assigned from a variable.
_CurrentCompData.FireProgress("Begin Initialize Service Client", 45, 10, 100, "Post Execute", ref(_StopExecution)); BasicHttpBinding bindingElement = new BasicHttpBinding(); EndpointAddress endPointAddress = new EndpointAddress(new Uri(_ServiceURL)); bindingElement.AllowCookies = false; bindingElement.BypassProxyOnLocal = false; bindingElement.ReaderQuotas.MaxStringContentLength = 2147483647; bindingElement.MaxBufferPoolSize = 2147483647; bindingElement.MaxReceivedMessageSize = 2147483647; bindingElement.HostNameComparisonMode = HostNameComparisonMode.StrongWildcard; bindingElement.ReaderQuotas.MaxArrayLength = 2147483647; bindingElement.ReaderQuotas.MaxBytesPerRead = 2147483647;//4096; bindingElement.UseDefaultWebProxy = true; bindingElement.MessageEncoding = WSMessageEncoding.Text; bindingElement.TextEncoding = Encoding.UTF8; bindingElement.OpenTimeout = new TimeSpan(0, 2, 0); bindingElement.ReceiveTimeout = new TimeSpan(0, 30, 0); bindingElement.SendTimeout = new TimeSpan(0, 20, 0); bindingElement.Security.Mode = BasicHttpSecurityMode.TransportCredentialOnly; bindingElement.Security.Transport.ClientCredentialType = HttpClientCredentialType.Windows; bindingElement.Security.Transport.ProxyCredentialType = HttpProxyCredentialType.None; bindingElement.Security.Transport.Realm = String.Empty; ServiceClient myClient = new ServiceClient(bindingElement, endPoint);
- Marked As Answer by plditallo Friday, August 17, 2012 2:32 PM
Thursday, August 16, 2012 2:52 PM
What I normally do when calling WCF service in SSIS is to create a custom library (proxy) compiled for .NET 3.5
1. Create new C# Library, Add Service Reference or use svcutil.exe.
2. Add a static method that accepts URL and returns the ServiceClient. The binding information is constructed here.
3. Strongly name the library deploy to GAC and put to C:\Windows\Microsoft.NET\Framework\2.0 folder for reference.
1. Add a new variable, that holds the Url of WCF.
2. In the script task, add reference to the library and pass the variable defined in # 1.
3. Add DTSConfig or add a /SET parameter when executing the SSIS package.
Randy Aldrich Paulo
MCTS(BizTalk 2010/2006,WCF NET4.0), MCPD | My Blog
BizTalk Message Archiving - SQL and File
Automating/Silent Installation of BizTalk Deployment Framework using Powershell >
Sending IDOCs using SSIS
Friday, August 17, 2012 2:29 PM
Thanks for your repsonse. Both your solution and Dinesh's solution work reliably. My colleagues here like Dinesh's, however anyone following this thread in the future should know that either works!:-)
Friday, August 17, 2012 2:32 PM
Thanks for posting your response. We happen to have a vendor that was using custom bindings to add to the excitement of successfully getting your solution to work, but the basic premise did work. I like that you posted enough of the solution to be helpful, especially the all import line: ServiceClient myClient = new ServiceClient(bindingElement, endPoint); !:-)
Monday, August 20, 2012 1:35 PMGlad i can help :)