Not sure exactly what you're trying to do or what problem  you're exactly facing (more details would be helpful) but, assuming you're trying to handle the soap body yourself instead of what the wizard generated then you can create a method to create the body and add the name to the WriteSOAPBodyMethod  property of the client class. It's not recommended to call Cache internal methods in your code. It's better to use any provided "hooks" if available.

If you want to check on the result of a LOCK command for example 

LOCK +<SOMERESOURCE>:<timeout>

IF $T {do something}

So I wouldn't call it bad practice just yet.

Agree with brace always. This really helps with new developers as the syntax is something they've seen before in other languages. 

I understand the accessing part but by creating a class mapping I'm enabling SQL access to the existing global. I guess that the question is more in line on whether sharding will be able to properly partition (shard) SQL tables that are the result of global mapping? Are there any constraints on how the %Persistent class (and the storage) is defined in order for it to work with sharding? Should they all use %CacheStorage or can they use %CacheSQLStorage (as with mappings)? 

Let's say I have an orders global with the following structure:

^ORD(<ID>)=customerId~locationId.....

And I create a mapping class for this global: MyPackage.Order

Can I use sharding over this table?

Alex, it's all based on your design. The decision of whether a method is an instance or class method is totally independent of whether that method can be private or not. Your design, and patterns or best practices you want to follow, will dictate which way to go. The benefits are in what you want to accomplish with the design: ease of testing, ease of change, etc. 

Can we infer form this that sharding can be applied to globals that have been mapped to classes (thus providing SQL access)?

Any restrictions on using a messaging/queuing system? 

The easiest way would be to change the definition from list to array. But if you can't do that the next easier thing is to change the STORAGEDEFAULT parameter to 'array'.  Both options will project the collection as a separate SQL table that you can join with.

You're totally right. I forgot about this syntax.

Can you add more information as what is the exact problem you're facing?

If you're accessing the database through ODBC you can craft the query with any name you need to. With that said, your option of having a variable with the name + a date should work as long as this variable is within your application (client). 

If what you want is for the database to handle the variable and the logic to assemble the table name then you need to go with a stored procedure as mentioned by Eduard.

The only "caution" here is that referencing the property by name only works with properties where the SqlFieldName corresponds to a valid Cache property name:

1. Property myproperty As %String;
2. Property myproperty As %String [SqlFieldName = "mysqlname"];
3. Property myproperty As %String [SqlFieldName="my_property"];

You can access #1 & #2 by property name, however #3 you can only access by using %Get("my_property");

Can you provide more details on what exactly you're trying to accomplish? As you said, the last query works. What exactly is missing? Are you trying to get a prompt (outside of Cache I'm guessing) with the parameter name?

Yeah, that's what I was referring to :-(

Cache doesn't provide this "out of the box" but you can always create a class that works as a Collection (a collection of IDs if you will) and provides an Iterator interface/functionality for to you iterate over the values.  You can always expose and access data through Objects as you need to.

There's no easy way for this (as far as I know) as most of this information is "hardcoded" to be written that way in the methods. 

You can always extend the WebRequest class (and its parents) and modify the methods to write the XML in a single line or however you want. However, this is very tedious and carries a lot of problems with each upgrade. 

$ORDER would do. Not the cleanest (or preferred) but the point being you can do without SQL.

You can manage without. You have plenty of Object Oriented options to get to the items.  Or you could use $O over the global to get the IDs (similar to what Extent would do)