I need to make Biztalk exchange data with an OPC A&E server, and it uses COM communication, so I'd like to know if I need to develop some kind of adapter or there's a direct way.
I have integrated with DCOM services from BizTalk by running .net code called from an orchestration.
For example:
using System.Reflection;
using System.Runtime.InteropServices;
string serverName = "My Server";
string progID = "My DCOM ProgID";
Type objType = Type.GetTypeFromProgID(progID, serverName, true);
object objLateBound = Activator.CreateInstance(objType);
Related
I am using IBM MobileFirst Platform Foundation 8.0.0. I have a Java Adapter that is deployed on the mobilefirst server that is calling an external service. After creating a resource on the external system, I return the created id on “location” response header. It gives me the complete url of the created resource of the external system like http://example.com:1234/resource_name/1234
I don’t want to expose the external system’s url to the caller / client of my adapter. I want to return something like this - http://mobilefirstserver.com:6789/mfp/api/adapters/MyAdapter/resource_name/1234
where "mobilefirstserver" is the server on which MyAdapter is running. I am unable to find any method from mfp libraries where it can retrieve “mobilefirstserver” and “6789”. I can retrieve the adapter’s target URI, which is “example” and “1234” from adapter.xml, but not the host and port details of the mobilefirst server.
Some options:
Use the configuration API to obtain it: ConfigurationAPI.getServerJNDIProperty("mfpadmin/mfp.admin.authorization.server.url") - this will be something like this: http://localhost:9080/mfp/api. You will need to extract the host and port from it.
You could use, on the client-side, the WL.App.getServerUrl API and use it as a parameter in your call to the adapter. But that little sense for your scenario (although I didn't fully 'get' what is the scenario).
Since the server is yours, you can simply hard-code these values in your adapter implementation.
Sorry if this has been raised elsewhere...
I am trying to consume a WCF service in vb.net. The application that is consuming the service sits behind a proxy server, and so needs to connect to the proxy server to get to the service.
In old school web references, this was easy to do with a couple of lines of code to set the proxy server for the web request.
Is there an equivalent way of doing it now? Preferably in such a way that the proxy address can be changed through configuration used in the application rather than amending app.config files.
I have a Flash AS3 client application that sends data to a VB.NET server application using TCP/IP. When testing using loopback/localhost on a single machine the data comes through. However, when I set the IPs of the sockets to the corresponding computers of the LAN and run each application separately, there is no data reception.
VB.NET - This works:
Public Shared localAddress As IPAddress = IPAddress.IPv6Loopback
Public Shared port As Int32 = 8080
Public Shared server As New TcpListener(localAddress, port)
AS3 - This works:
var client : Client = new Client("localhost", 8080)
AS3 - This doesn't:
var client : Client = new Client("xxx.xxx.xxx.xxx", 8080)
I have checked that the port is open (i.e. ShieldsUp returns "Stealth"). I am not sure if I should be using NetConnection instead or if I could/should set up a Flash socket policy file - both computers are running Windows.
What is the most plausible reason for no connection? Any ideas?
Have you got a socket policy file in place? http://www.adobe.com/devnet/flashplayer/articles/socket_policy_files.html
Also, set up policy file logging so you get an idea of what's going on: http://help.adobe.com/en_US/flex/using/WS2db454920e96a9e51e63e3d11c0bf69084-7ec4.html
Also, final (dumb) point: are you sure both computers are on the same network, and that the ip is right (lan ip, not public ip)?
I am new to WSDL.
We have done a project on WSDL in VB and call service via PHP SOAP function which works fine in Localhost but not in live.
We came to know that problem in Default Namespace.
When tried to access the host it sent service called "GETUSERINFO" . But service sent to default as "http://tempuri.org/iservice/GETUSERINFO" and returns "Could not connect host".
Question is
1. Why Default Namespace not connected in Host but in Local?
2. Where to change the Default Namespace?
Thanks
I believe you need to publish your service first and the update your reference in Visual Studio with the new address so it can generate that information for you.
I'm working on an app and I need to provide a web interface to it. I was thinking about using WCF to provide a service for the web interface, and self-host both with my app (no IIS). Now, if those two are not using the same port, the browser will complain about XSS...
Is this possible? Is this a good idea?
EDIT
After some investigation, I've managed to make it work.
Here's the webservice self-host code:
var serviceHost = new ServiceHost(typeof(CalculatorService));
serviceHost.AddServiceEndpoint(typeof (ICalculator), new WSHttpBinding(), "http://localhost:8000/webservice");
serviceHost.Open();
Console.WriteLine("CalcService is running.");
Console.WriteLine("Press Enter to terminate the service.");
Console.ReadLine();
serviceHost.Close();
And here's the web host code:
var listener = new HttpListener();
listener.Prefixes.Add("http://localhost:8000/webconsole/");
listener.Start();
Console.WriteLine("listening");
while(true)
{
HttpListenerContext context = listener.GetContext();
/* ... */
}
For the webservice to work, I needed to do this
Yep- works fine. HTTP.SYS abstracts the HTTP stuff that WCF uses, and it allows an arbitrary number of processes to share the same port as long as they're all using different path prefixes. I do this all the time for exactly the same reason.
This won't work on XP in IIS 5.1 or with the VS webserver, though- just in case you were going to try. They're not HTTP.SYS based, so they expect to get their ports exclusively. Anything else, though (including XP with 2 WCF hosts), you're good to go.
Sounds fancy, I'll have to watch this one. If nothing else works, you could keep it as two separate ports but then maybe use a reverse proxy to sort out the WCF endpoint?