Communicating with external VB.Net process

[TimPGade]

I want my external app (which is a VB.Net Windows Form application) to be
able pass back results to InfoPath without having to use external files (ie.
temp files or sql server). My idea is to use Remoting.

I would like to add Remoting capabilities to my IP Form so that I can
establish InterProcess communications with another VB.Net application that I
lauch from IP as a new process thread.

My goal is to have IP become the Remoting Server and have the external app
as the Remoting Client. I have built simple Windows Form projects
that consists of a Server.exe and Client.exe and communicate via tcp on port
9080.

When I embed the "server" code into my IP form (which is nothing more than
setting a reference to the RemoteObjects.dll and executing the following
command:
RemotingConfiguration.Configure("SimpleServer.exe.config")), my client
application is not able to find the server on the designated port.

The end result I am hoping to achieve is to have my external app (which is a
Windows Form application) pass back results without having to use external
files (ie. temp files or sql server). I need this because some of the
WebServices I use may not return the results in a timely manner, and because
IP does not support Async communications, I plan to catch the timeout error
and give the user the option to launch an external app that can wait on the
WebService and then notify IP when the results are available via a remoting
callback.

If I could eliminate the need for UI in my external app I can use the
Process stdin and stdout redirects to pass a stream back to the IP form.
Since I do need the UI, I am temporarily stuffing the base64 stream in a SQL
binary field and passing back the RowId as the ExitCode and trapping the
Process.Exited event. There is at least one advantage of doing it this way as
I can query SQL from IP at a latter time to see if the results have been
posted (in the event I miss the event). Right now the SQL/file based overhead
is a little too costly.

Launch external app
External app posts to SQL
External app has to close
IP has to fetch from SQL
IP has to dispose of SQL record

vs.

Launch external app
External app calls IP via remoting

Any ideas?

 

[Roland]

I want my external app (which is a VB.Net Windows Form application) to be
able pass back results to InfoPath without having to use external files (ie.
temp files or sql server). My idea is to use Remoting.

I would like to add Remoting capabilities to my IP Form so that I can
establish InterProcess communications with another VB.Net application that I
lauch from IP as a new process thread.

Any ideas?

hi tim

i have a similar requirement, and am currently using files, which is a
bit naff. the solution i am looking at is to host a thin Web Service
from my UI application using WSE 2.0 (which eliminates the need for
IIS on your client PC btw) and for InfoPath to post the form data to
that web service.

as web service integration is already fully supported within InfoPath,
this means you don't have the problem of writing (and maintaining)
code at both ends, like you would have to with remoting. web services
act asynchronously, like remoting, but you don't have the headache of
all the multithreading code you have to write.

also, for future scalability you could very easily move your web
service off the client to a server at some point with no changes
required at the InfoPath end. your client application could then be
alerted by the server that data had been received or changed.

obviously, all the IP form needs to know is the URL of the web service
- this can be passed by your UI application on the IP command line,and
can be parameterised so that your web service coughs up a specific
record (like a query) for editing.

i have worked with remoting before, which is great for highly custom
messaging, but i wouldn't bother with it for intergating an
application like IP which already has such rich support for web
services.

hope this helps.

roland

 

[TimPGade]

Hi Roland,

Thanks for your reply. Well stated perspective on web services. It is my
understanding that IP unfortunately does not support Async calls. I have not
found a way to circumvent IP timeouts for long running webservice calls.
Async in IP would be ideal for external processes (i.e. web services) that do
not require UI.

In my case, my external process launches a custom web browser that walks the
user through a series of web forms and auto-populates fields with IP data via
mshtml (for example filling out a parts order from a web supplier). Once the
order is filled out and submitted, I capture the response stream and parse
the confirmation information to pass back to IP. Currently I am using temp
files and and/or sql server to pass the results and trapping the
Process.Exited event and stuffing the RowID in the ExitCode to notify IP that
the results are ready for consumption.

I want to eliminate the SQL connection overhead and temp file management
overhead using remoting and send the results directly to my IP form as a
memory stream. At first blush, It looked like a couple of lines of remoting
code was going to be my answer. If I could only understand why the remoting
client cannot find the IP host I would be a happy camper.

If you can think of other alternatives, please let me know.

Thanks again,
Tim