F# web service data provider with local wsdl file - f#

I am trying to write F# client for our web services. The example here looks very good except it uses the server url in the code.
type TerraService = WsdlService<"http://msrmaps.com/TerraService2.asmx?WSDL">
This prevents me from reading service url from configuration file at run time, and make deployment from dev server to production server difficult.
I am wondering if there is any WSDL provider that works similar to Dbml Provider

I'm not sure I understand exactly what you're looking for, but note that the URL provided as a static parameter is used to generate types, but if desired a different URL can be provided at runtime by using a different overload of the Get...Soap method. This URL can come from wherever you want (e.g. you can read it from a config file if that's your scenario). E.g.:
type TerraService = WsdlService<"http://msrmaps.com/TerraService2.asmx?WSDL">
let terraClient = TerraService.GetTerraServiceSoap(EndpointAddress(myRuntimeUrl))

Nothing currently exists that does that but the code is open source so you could make a version of it that work's in the mode that you desire:1 2.

Related

OData Type Provider problem with Socrata hosted data sets

I am trying to access Socrata (open government) data sets using the F# Type Provider for OData v2. Why does the Type Provider consistently fail on what looks like valid OData service? I've tried both their simple demo and more complicated data sets like https://data.edmonton.ca/OData.svc/q7d6-ambg
I am using a small fsx file with VS Code, though I've tried with a full blown project, too.
#r "System.Data.Services.Client.dll"
#r #"C:\Users\protium\.nuget\packages\fsharp.data.typeproviders\5.0.0.6\lib\net40\FSharp.Data.TypeProviders.dll"
open FSharp.Data.TypeProviders
type Svc = ODataService<ServiceUri = #"https://sandbox.demo.socrata.com/OData.svc">
I should get back static types to access the service.
Instead, Intellisense gives me back error 7001: Schema specified is not valid but these OData providers work fine in Excel. Socrata allows either v4 or v2 of the OData standard.

Force weblogic to exclude IncludeTimestamp from generated wsdl

I have an EJB that plays the role of my web service class too. I use Oracle Weblogic 12.1.2 as JavaEE container.
Here is the code of that class:
#Stateless
#WebService(serviceName="MyService")
#Policy(uri = "Wssp1.2-2007-Https-UsernameToken-Plain.xml", attachToWsdl=true)
#XmlAccessorType(XmlAccessType.FIELD)
public class MyWebServiceBean{
// some web methods ...
}
The attached policy and its corresponding wsse tags is properly can be seen in generated WSDL file. However, there is a IncludeTimestamp tag in the generated file that forces clients to send Timestamp in their request. As in my environment clients may have different times, I perefer not to force them to send the time! Then I simply omit the IncludeTimestamp Tag from the server wsdl and everything goes well after that! But I do not want to handle it by hand. Is there any setting in weblogic 12.1.2 to configure existence of mentioned tag?
After a lot reading and searching for this matter i found that we should create Custom Policy. Firstly we should find the xml file of the desired policy. Flow this post to do so. Then we should edit it and copy the edited version in our classpath and for #Policy annotation we should use new address of our xml file! That's it.

OpenESB - different environments

I am developing a service layer app which provides a catalog of webservices, then I am orchestrating them using OpenESB.
I create my BPELs importing external WSDL definitions using http://localhost:8080/services/myService?wsdl.
The problem is -- these BPELs strongly depend on this specific URL, and when I deploy on production server, my ESB layer stops working.
How can I make my BPELs independent of the specific endpoint? Can I refer the URIs to an external config file?
To do it you must create application configuration and application variable and add them on your http address. Example: "http://${MyHtttpAddress}:${MyHttpPort}/service1/myService?wsdl"/>.
Applications and variable are set up in the administrative console and can be changed for each environment.
Regards
Paul

Using app.config to determine a common config file

I am doing a windows service, using app.config, where there is a section to retrieve common configuration in another file. Using
AppDomain.CurrentDomain.SetData("APP_CONFIG_FILE", "filepath\\file");
works for me, but using
string appconfig = ConfigurationManager.AppSettings["CommonAppSetting"];
AppDomain.CurrentDomain.SetData("APP_CONFIG_FILE", appconfig);
does not. It gets from the app.config of the windows service instead of the common configuration.
Anything I did wrong, or is there other better ways of doing it?
You need to reset some variables (ClientConfigPaths) in the ConfigurationManager in order for it to refresh its values. These can be seen in the following accepted answer (complete with code for doing this legwork).
Change default app.config at runtime

How to influence the URL to access a registered Delphi WebService

We've written a webservice dll with Delphi XE2 and it is running in our IIS7 server, accessible with the url http://server/webservice.dll/soap
To be able to debug the service, I've created a webservice.exe project, which can be run in the WebAppDebugger of Delphi. The problem now arrises that the webservice running in the debugger is accessible with the url http://localhost/webservice.webservice/soap
Our client application has the last part of the url "webservice.dll/soap" hardcoded (security reasons) so i cannot change that when testing with our client application, the server-address part "http://server/" is configurable in the client.
So, my question: How can i register the debug service in my webappdebugger to use an url like my production dll?
I've found the solution myself ;-)
In the initialization of the debugform there was the following line:
TWebAppSockObjectFactory.Create('Webservice');
changing this to:
TWebAppSockObjectFactory.Create('dll');
made the overall address change to http://localhost/Webservice.dll/
This did leave a small problem that the debugger project had to be renamed to Webservice.exe in stead of WebserverDebug.exe as it was called, but moving it to subfolder made this rename possible.

Resources