[Looking for Charlie's main web site?]

Still more reasons to make sure you have updated your ColdFusion 10 web server connector

Note: This blog post is from 2013. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.
Several weeks ago, I did an entry, CF911: Why/when you MUST update the web server connector for #ColdFusion 10, and may have missed it.

In this entry, I want to throw in another reason why it's important to make sure you properly update (reconfigure/rebuild/upgrade) your web server connector after applying certain CF10 updates, or if applying only the latest update for the first time to a newly installed CF10 instance.

[....Continue Reading....]

Using tools to browse Web Services. Great for solving problems

Note: This blog post is from 2009. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.
I just blogged about a feature in CFBuilder that allows you to browse web service methods, arguments, etc., like the same feature in Dreamweaver and the Adobe Eclipse Extensions for Eclipse.

But what if you have none of those tools, or just don't care to fire them up?

[....Continue Reading....]

CFBuilder tip: Browsing web services--did you know you can? and a bug you may hit

Note: This blog post is from 2009. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.
Did you realize that you can browse web services in CFBuilder (just like you could in Dreamweaver or the Adobe ColdFusion 8 Extensions for Eclipse), seeing all the methods, their args, etc.? I'll show you how, but I'll also warn of a bug you may hit in the beta, and give a simple solution.

This is another in a series of tips I want to start share for those working with CFBuilder. While oriented mostly to those who had not used (or stuck with) CFEclipse before, this one may surprise even folks who had used it.

[....Continue Reading....]

CF8 Hidden Gem: New option to save java source for web service proxy--with createobject only

Note: This blog post is from 2007. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.
Have you ever wanted to see the Java source code for the proxy/stub that's created when you invoke a web service from Coldfusion? Well, here's a hidden gem in CF8 (one of dozens I discuss in my "hidden gems in cf8" talk) that does just this.

Curiously, it's only available when you invoke a web service using createObject(), not CFOBJECT or CFINVOKE.

It's enabled using the new ArgStruct argument that I discussed last month.

<cfscript>
wsargs = structnew();
wsargs.savejava="yes";

convert=createobject("webservice","http://www.webservicex.net/CurrencyConvertor.asmx?wsdl",wsargs);

writeoutput(convert.ConversionRate(FromCurrency='USD',ToCurrency='EUR'));
</cfscript>

You may wonder why you have to put it in this argStruct when it's the only key being put in the structure. That's just the way it is. Of course, I could have created the structure using the new implicit array creation syntax, as in:

wsargs = {savejava="yes"};

which replaces 2 lines with 1.

For those who don't care for CFSCRIPT

Of course, you don't need to use CFSCRIPT to use createObject, for those not comfortable with it. I could just as well have done it all in tags, as:

<cfset wsargs = structnew()>
<cfset wsargs.savejava="yes">

<cfset convert=createobject("webservice","http://www.webservicex.net/CurrencyConvertor.asmx?wsdl",wsargs)>

<cfoutput>var="#convert.ConversionRate(FromCurrency='USD',ToCurrency='EUR')#</cfoutput>

Where the Java source is placed

So where is the Java placed? In the same directory where the java proxy stubs have been placed since CF6: [coldfusion]/stubs/. In the case of the standalone version of CF8, that might be c:\coldfusion8\stubs.

Each invocation of a web service in CF (whether you use the saveJava option or not) will create a directory there, typically in a form like WS729914123 (one for each separate web service invoked by any CFML requests), and within the subdirectories of that directory you'll find class files reflecting the name of the called web service.

If you don't use the saveJava option, you'll see only class files. If you'll see corresponding .java source files for each.

Finally, note that the Java source files will be removed automatically if the web service is refreshed (manually or in the CF Admin) and you call it without the SaveJava option (which also means if you invoke it using CFOBJECT or CFINVOKE).

(*Update*: In the original entry, I said the source would be removed if you called the web service without the SaveJava option, but I should clarify that it's if you do that and you cause the web service to be refreshed, not just any call, since that would use the compiled result of the earlier call unless you told it to do otherwise.)

Still, for those who have long wished to better understand these Java proxy stubs, it's nice that we have the option to see the source if we want to.

Still more to come

There's still more power in CF8 for those that like to tinker with the java proxy/stub generation. More on that in a later entry.

CF8 Hidden Gem: New ArgStruct argument for createObject with web services

Note: This blog post is from 2007. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.
Here's another hidden gem in CF8: did you know that there's a new optional "ArgStruct' argument for use with createObject(), when using it to invoke web services?

Following on my previous note about a new RefreshWSDL option in CF8 for CFINVOKE and CFOBJECT, I mentioned there that it was also an option in the createObject() function, but naturally it can't be passed as a tag attribute like with those above.

Instead, it's enabled using this new ArgStruct argument. Technically, it's not "named" ArgStruct but rather it's simply a new optional 3rd argument you can specify when invoking a web service (the term "argStruct" simply comes from the CF docs for the function, where it refers to it by that name. (While yo umay notice that the docs indicate this also allows setting a timeout for the web service invocation, note that that only times out the requesting of the WSDL, not subsequent method calls against the object.)

Anyway, in that structure you create, you simply define RefreshWSDL as a key within it, all of which is passed into the createObject() function as that 3rd argument:

<cfscript>
wsargs = structnew();
wsargs.refreshwsdl="yes";

somevar = createobject("webservice","http://[server]/[webserviceurl]",wsargs);
...
</cfscript>

Of course, you could just as easily do all the above in 3 CFSET tags. It doesn't matter. The key is the addition of the 3rd argument to the createObject(). And it doesn't matter at all what you call the structure (I named mine "wsargs").

Now, you may think this approach seems clumsy, and ask, "why didn't they just permit the refreshWSDL itself as a new argument on the createObject()?". It's a fair question.

But it turns out there's actually a little more to this new ArgStruct option, and it's different enough that I'll talk about it in a separate entry.

CF8 Hidden Gem: Refreshing Web Service WSDL and CF proxy/stub with new RefreshWSDL option

Note: This blog post is from 2007. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.
One of the many hidden gems in CF8 (and I've found dozens of them) is a new attribute on CFINVOKE or CFOBJECT (and argument for createObject) called RefreshWSDL. It's a another solution to the long-standing problem of invoking web services whose metadata may have changed since previous executions. I'll explain the older approaches, some new in CF 6 and 7, later here for those who missed them.

So what's the problem it solves? If you have CFML code that calls a web service, and one day it just stops working, the problem may be that the web service itself has changed. Perhaps the owner changed the return type or some other metadata.

The new solution allows you to refresh that WSDL on the CFINVOKE or CFOBJECT tags, or the createObject method.

Doing it in CFINVOKE/CFOBJECT

Here's how to do it in CFINVOKE.

<cfinvoke webservice="http://[server]/[webserviceurl]" method="[methodname]" refreshWSDL="yes" ...

Adding it as an attribute for CFOBJECT would work essentially the same way, for those familiar with that tag.

Doing it in createobject()

Doing it in the createObject() function, however, is quite a bit different and leverages some new syntax for that function. I'll show that in another blog entry and will point out another new feature for that function.

There are a couple more points to consider about this, but first I just want to explain why it's needed, for those who haven't heard of such options.

Why should you have to refresh the web service metadata?

Just to back up for a moment, the problem stems from CF's attempt to help. On the first request for a given web service, CF does some caching to make future requests go faster, not caching the results of the web service method but rather the artifacts used by CF based on the description of the web service itself.

CF uses the web service description (WSDL) reported at the time of that first call to create a java proxy/stub based on that, which it then reuses on future calls from CF to that web service.

The issue arises if/when the web service metadata changes. CF won't know, and will continue to use the older cached proxy/stub, and your long-running code may fail if it doesn't match the new WSDL returned by the web service.

So we need a way to tell CF to refresh its cache of that proxy stub.

This new feature is certainly the easiest way to make that happen, but it's not the only way.

Not the only way to refresh the cache, but the easiest

Some may know (and I've written previously) about two programmatic ways to refresh the proxy/stub, whether you're using CF7 (which added a new method in the Admin API) or using CF 6 or above (using an undocumented/unsupported service factory method), as well as an available button in the CF Admin console that could do it (since CF6).

A benefit of this new approach is that it doesn't require you to know the CF Admin password.

Easier, yes, but could be used inappropriately

Of course, with power comes responsibility. You don't want to leave this indicator in your code for all requests, such as in production. That would force CF to do extra work on each web service invocation, defeating the whole purpose of the caching. It's like the tools CFLOG or CFTRACE. Well, more like the former. At least the latter has an Admin console option to disable it even if left in production code.

It's one of those things where opinions will differ. On the one hand, the ease of mistakenly leaving this in to get into into production could make one argue that it ought not be in code, or at least should not be in code calling the web service but rather code to manage the cached stub itself, which is what the previous features did.

On the other hand, those required admin access to perform (except for the unsupported servicefactory approach). Similarly, even if there WAS an option to disable refreshwsdl in production, you'd be stuck if you needed to refresh the cache in production and had no admin access.

At least we have the choices now, and forewarned is forearmed.

Finally, as for more CF 8 hidden gems, I'll note that I've got a user group presentation on the topic, and I have a few dozen more I share. I'll start sharing more of those in blog entries.

Reloading CF web services programmatically, using the CF7 Admin API

Note: This blog post is from 2006. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.
I'm surprised to not see much out there about how to reload or refresh CF's cached WSDL proxy for calling a web service, at least programmatically using the new CF 7 Admin API. Perhaps it's because people have been tripped up, or simply haven't explored it. Either way, I'd like to offer here the code you need, and also point out some tips and traps.

Update for CF8: As an update to this entry from 2006, which is focused on CF7, I'll note that there was yet another approach that was added in CF8. Both still work and have their own value. More on the CF8 feature in my later blog entry. Still, the feature added in CF7 is important to understand, too, so please read on.

[....Continue Reading....]

Handling optional arguments to web service method calls in CFMX 7

Note: This blog post is from 2006. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.
Have you tried to invoke a web service method from CFML when it declares optional arguments, and you don't pass in those optional arguments? You get an inobvious error message. Well here's good news: there's a new solution in CFMX 7, with CFINVOKEARGUMENT's Omit="yes|no". Very nice.

Thanks to Steven Erat for pointing this out.

For those who have seen my presentation on CFML web services (at CFUNited and over the past few years in other venues), this has long been a sore spot for me. So glad to see it fixed.

Copyright ©2024 Charlie Arehart
Carehart Logo
BlogCFC was created by Raymond Camden. This blog is running version 5.005.
(Want to validate the html in this page?)

Managed Hosting Services provided by
Managed Dedicated Hosting