Anyone using Access/VBA to interface with web services who has used

a) WSDL.exe to generate a .NET client and then added the necessary
"wrapper" and whatever else is necessary to enable it to be called from
VBA code in Access?

or

b) Used Visual Studio to generate a similar .net client (there is an
automated tool in VS that does a similar job in generating the .net
client) and successfully specified the COM access capability such that
you could call it from Access/VBA?

Either of the above approaches would appear to be the most current and
recommended - just I can't figure out how to do so and make it callable
from Access/VBA.



Currently I am using pre-assembled SOAP commands in a table that I send
using XMLHTTP. As I recall, this is the method used by and recommended
to me by Albert Kallal. This works well although to modify parameters I
have had to set dummy strings (ex. XXXXX or YYYYY) in the SOAP and then
use find/replace to set the current date or other changeable parameter.

I have tried using the Web services toolkit in Access/VBA but it does
not allow me to add fields to the SOAP header that are required by my
web service. My web service, built by a third party, requires
authentication data to be submitted in the SOAP header.(I have read that
it is possible to utilize custom IHeaderHandler and related classes to
achieve this but so far I have been unsuccessful.

I have also tried using PocketSoap which is a nice toolkit, free. I am
almost there with PocketSoap - I can create the custom SOAP header I
need as well as the complex data consisting of 6 fields in a structure.
SO far I can send and receive so I know I am talking to the web
service. I have not resolved all the issues in getting it to understand
the SOAP message I am sending. I am using Fiddler 2 which is a very
nice free tool to watch the soap messages to and from. Fiddler 2 now
handles HTTPS messages which is what I am required to use.

surely someone out there has been successful with one of these methods
that have so far eluded me.

bob

Sorry Bob - I don't have an answer. I need to figure out how to get
credit card verification working with Access 2010 and web services. I
certainly hope I will be successful. From what I remember the vendor
telling me, it sounds so much like what you are trying to do!

On 1/21/2012 5:03 PM, PW wrote:
may find that the Web Services Toolkit ver 2 in Office works quite well.

Bob

"BobAlston" wrote in message news:jf9u5m$uk7$1 (AT) dont-email (DOT) me...

Break this down into steps:

#1) Are you comfortable using .net and consuming web services now?
There is tons and tons of examples.

You don't need or want to care about using such examples with Access.

On the other hand, if you not comfortable doing the above, then converting
that into a com object
for use in Access not going to be that helpful for you, is it?

The second part, is once you crossed the bridge of using web services in
..net, then the NEXT
step is how to use a com object in Access. (separate issue/separate
question).

There is a thread here in which I just helped someone register a .net object
for use in Access.

http://social.msdn.microsoft.com/For...4-e592cdd4f9c9

The advice in the above is step #2. In other words, you don't need necessary
a example of using web services from .net in Access, but :

a) how to use/consume web services in .net. If you comfortable doing this,
then you need step b)

b) how to convert some .net code into a .dll and ActiveX (com) object for
use in Access.

The above is two separate skills.

No, don't use dummy strings, and don't use find/replace. You have
this "fantastic" xml library system that lets you manipulate that xml
data. I mean to pull out a list of web sites returned from a SharePoint
web services, I don't use find/replace, but use this in xml:

Set w = myNode.SelectSingleNode("//Webs")
For Each w2 In w.ChildNodes
Debug.Print w2.Attributes(0).NodeValue, w2.Attributes(1).NodeValue
Next

The above is pulling the "node" called Webs out of the xml. So I don't use
VBA functions here.

If you going to use the XML library, spend some time reading and looking at
some of the MSXML examples not just for web services, but the tons of
examples that shows you how to simply manipulate XML using MSXML. You want
to be able to "play" with that XML in the sense of being able to change
values, and pull values out. Again, don't necessary use web service
examples. Learn this ability. Without this ability to use the MSXML library,
then it really much a waste of time to use MSXML for web services. This is
really again like the .net issue. Without .net, it don't make much sense to
worry about converting something you can't use well in the first place into
a com object for Access.

You should not need to use dummy strings, but reference the structure(s)
using the xml library.

So, in the case of me suggesting to use .net:

This road only makes sense if you able to work with and use .net to consume
web services (and the billions of examples on the web of doing so).
If your comfortable consuming web services in .net, then you take (leverage)
that knowledge and build a .net class that you can convert into a ActiveX
(com) object.
However this suggestion results in you having to install + register a
ActiveX control for deployment.

I mean, most of us and the Access community has quite much suggested to
avoid using ActiveX with Access for 10+ years now. Now of course this is not
the end of the world, but going down this road and having to distribute an
ActiveX with your Access application is serious decision and one that ONLY
YOU can make and commit to.

My point here is if you going to adopt .net and use that .net code from
access then you are adopting the responsibility of distribution of ActiveX.
For some, this is a non issue, for some it is a deal breaker. And if you
been using ActiveX controls in Access, then this is likely a non issue for
you.

On the other hand if you not used .net to consume web services, then again,
you have to decide to you want to learn this road or not. (again, only you
can decide this choice).

My other suggestion:
Use MSXML:

This road only makes sense if you spend a bit of time learning how to use
MSXML to work with XML (so I not even talking about web services here, but
just using the XML system). The idea that you going to work and use dummy
strings and "replace" commands in VBA is just not a practical decision and
one that I would not suggest to people I dislike let alone my developer
community here!

You want to use the XML library to modify "node" and attributes of that XML
that has structure. I also spent a good deal of time pointing out that
using MSXML would not make sense if you have "tons" of methods to deal with.
However, for just a few, it likely far less work then going the .net road.
Then again, it depends - if you are up to speed using web services in ..net,
then you ONLY need to build a class object and then "learn to" register it
as a com object as the link in the above discussion shows (and it is easy as
the discussion shows).

However as noted this .net road does create a deployment dependency. (so
your policy may be "no way" or "no problem" - I don't know your case and
again this will be YOUR choice + call).

So break these things down into steps.

Which ever of the bits and parts above you are more comfortable working with
will much suggest what road is going to be the one of least resistance here.

You need steps, and one skill set gives you the next step. If you
comfortable with MSXML to manipulate XML data, you can THEN consider using
it for web services.

In my experience, if something seems too difficult, it usually means that is
the wrong road is being taken, or a step in skills is being skipped. One
skill step leads to the next.

--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
Pleasenospam_kallal (AT) msn (DOT) com

On 1/21/2012 8:16 PM, Albert D. Kallal wrote:

It will take me a while to digest all that you have written.

However, I am pleased to report that I have been able to use Visual
Studio 2010 and created a web services client proxy dll and got it
registered to COM. I am able to see the method and the structures
including the soap header custom authentication header structure.
The key seems to be to use VS 2010 and not VS 2003 which I had been using.
I am getting an error when I try to set an instance of the SOAP header
object but I read that applying all Office updates can cure that (I am
running this on a laptop I recently inherited from my daughter and just
installed Office 2003 and a 30 day trial of VS 2010).

Regards,

Bob

On Jan 21, 9:19*pm, BobAlston <bobalst... (AT) yahoo (DOT) com> wrote:
Unfortunately, it appears that the COM visible DLL created from VIsual
Studio 2010 via the web service generation capability is not usable
from Access/VBA because it contains references to a custom class
containing authentication data in the SOAP header. See another thread
where the Microsoft moderators said it cannot be done.
http://social.microsoft.com/Forums/e...-55a35589cf2b/

So my workaround of XMLHTTP is working. Yes I could use the XML
library to "properly" use the XML/Soap data being sent, and modify the
parameters via XML.
But since soap toolkit was deprecated and the web services toolkit was
also deprecated and I read from Microsoft that the "recommended" thing
is to use VIsual Studio .Net or the WSDL.exe program to generate
a .Net dll and make it visible to my "unmanaged code" (e.g. VBA), I
was trying to do just that.

Bob