Like others have said, a /search endpoint is inherently non-RESTful.  Are you certain that /search endpoint shouldn't be something else? 

For example, if the search is searching people, then perhaps redesign it as a /person endpoint instead?  If that's the case, then a GET request to /person with URL parameters is definitely the most "RESTful" thing you can do; you're asking for ("GETing") information for a bunch of person resources.

If /search is really what you want, then it's not really following the RESTful architecture anyway, because you aren't asking for information about resources, you're really just asking the server to take an action for you and send you the result.  In this case, you might as well forget about RESTful conventions and just do whatever is most convenient and maintainable. 

I suspect that the user is filling out some sort of a form in the UI with these search parameters.  If that's the case, you might be able to simply POST the object that the form generates to the server, and then pull the parameters out of the request body in your server-side handler method.  In general, whether you're pulling the parameters out of %request.Data or out of  %request.Content, there isn't much code that needs to be written on the server.  So pick the option that makes the client code the most straightforward.

A few more details about your exact use case would help me give a better answer here.  As for the exact questions you asked, here's an example of the syntax you can use to write a query as part of a class:

Query Orgs() As %SQLQuery(CONTAINID = 1)
SELECT ID As OrgID,Name,DisplayName FROM Org ORDER BY Name

As for getting the query result as JSON, I asked a similar question a little while ago, and this discussion was very useful:

Now, if your real question is something along the lines of "I want to write a REST endpoint that gives me back the result of a class query in Person as JSON", then unfortunately that's a non-trivial problem.  The fastest way would be to write some endpoint, like /basicpersoninfo, and have the REST handler route requests for that endpoint to a method that uses JSON_ARRAYAGG and JSON_OBJECT and dynamic SQL  (discussed in that other thread) to write out the results of that query in JSON.

Oh, okay!  I think the fastest way to get to what you want would be front end form validation.

Whatever you're using to build the UI that leads to this JSON post, have that code mark certain fields as required, and then alert if those aren't filled.  In general, I think in the division of labor that task typically falls to the front end.

In theory, you can write a server method that scans the input before JSON import and then throws a custom exception with all the missing fields, but that's likely more work than doing it on the front end (because the front end will still have to catch that, then assemble the alert message from it anyway).

Also, if you're going to be changing which fields are required a lot, you can (in theory) write a server method which exposes which fields are required, instead of hard-coding that in the front end, but, again, that's likely not worth the effort.

Any of that helpful, or am I misunderstanding the problem?

You're running into the fact that calling %Get on a dynamic object doesn't return an undefined when data at the index you specify doesn't exist.  Instead, it returns "".

Both the answers you have here are great if you need a generalized solution.  If all you're looking for is a simple work around in a non-general case, all you need to do is check if your %Get returned "",  and if so, kill the value before you pass it in:

ClassMethod passIncompleteJSON()
  set json = ["arg1 val", "arg2 val"]
  set arg1 = json.%Get(0)
  kill:(arg1="") arg1
  set arg2 = json.%Get(1)
  kill:(arg2="") arg2
  set arg3 = json.%Get(2)
  kill:(arg3="") arg3
  write ..threeArgs(.arg1, .arg2, .arg3)

ClassMethod threeArgs(a, b, c)
  set:($get(c)="") c = "default"
  return a_"."_b_"."_c

Just be sure to pass in the parameters by reference since you're going to be passing in undefined variables.

(This does remove the distinction between undefined and "" though; you wouldn't be able to intentionally pass "" with this solution)

I'm guessing you're looking for the %%ID special reference.  Something like this:

Class Testing.TestingCalcProps Extends %Persistent

Property user As %String;

Property a As %String [ Calculated, SqlComputeCode = {set {*} = {user}_{%%ID}}, SqlComputed];


I'd recommend the Calculated keyword, as elements only gain id's after they're saved, which could perhaps lead to inaccurate values in the calculated property before the saving happens.

Here's the resource which talks about these properties:

And here's the one that mentions %%ID:

The post build script executes on the node that the Jenkins build ran on.  Therefore, that node machine is “local” for the purposes of copying remote files, and the machine where the XML file you want to copy lives is the “remote” machine.

You’ve probably seen this, but here’s the documentation for the Secure Copy Protocol (scp) command:

The relevant form for you should be:

scp user@hostOfFileToCopy:/path/to/fileToCopy /path/to/newCopy

“user” needs to be the name of a user who has permissions to copy the file. hostOfFileToCopy identifies the machine on which that XML file lives (could be an IP address). /path/to/fileToCopy is the absolute path, on that machine, of the file you want to copy.

/path/to/newCopy is the absolute path for the destination of the copy on the machine the Jenkins build is running on, not just the relative path from within the Jenkins workspace.  For example, while your path within the Jenkins workspace might be “/ReportFiles/Results.xml", the absolute path on the machine is probably something like “/Jenkins/workspace/ReportFiles/Results.xml”

Hope this helps.

It appears that, for whatever reason, the System files are not automatically included for every class you write in Cache 2010.  When a class inherits from %RegisteredObject, you don't need to worry, because they'll be included via inheritance.  For other classes, like the one where I was seeing this issue, the system files are unavailable unless included by hand.

Adding Include.%occStatus to the top of the non-compiling classes fixes the issue for the $$$OK macro, although a better practice is to use Include.%occInclude, to get some other standard stuff with the status routines.