Hi Sebastian - You are correct in that I implement it all directly in the Operation and the BPL handler with respect to getting the token (Handled in the Operation) and the storing of it (handled in the BPL.) I am not currently using any %OAuth framework functionalities though I have started to peek at them. They don't seem to match my use-case and perhaps it has something to do with how the vendor I'm working with has implemented their OAuth messaging.

My GetBearerToken function ends up looking something like this - below is any early working version. I have since cleaned things up and encapsulated a lot of the build-up of the %Net.HttpRequest object using a custom framework I developed but this will give you a general idea.

My custom message classes extends Ens.Request (or Ens.Response as appropriate) and %JSON.Adaptor. The properties defined within are aligned with what the vendor expects to receive or send back. For instance, when sending this request to the vendor, they typically expect a Client Id, Client Secret, and the Audience and Grant Type being requested for the token. My BPL defines all those properties dynamically before sending the call to the operation.

/// REST WS Method to fetch an environment specific OAuth Bearer Token.
Method GetBearerToken(pRequest As MyCustomMessageClass.Vendor.Request.GetBearerToken, Output pResponse As MyCustomMessageClass.Vendor.Response.GetBearerToken) As %Status

// Endpoint for retrieval of Bearer Token from Vendor
Set tURL = "https://vendor.com/oauth/token" 

Try {

Set sc = pRequest.%JSONExportToString(.jsonPayload)
THROW:$$$ISERR(sc) $$$ERROR($$$GeneralError, "Couldn't execute object to json conversion") 

// ..%HttpRequest is a reference to a class defined variable of type %Net.HttpRequest.
// Set HTTP Request Content-Type to JSON
Set tSC=..%HttpRequest.SetHeader("content-type","application/json") 

// Write the JSON Payload to the HttpRequest Body
Do ..%HttpRequest.EntityBody.Write()
tSC = ..%HttpRequest.EntityBody.Write(jsonPayload) 

// Call SendFormDataArray method in the adapter to execute POST. Response contained in tHttpResponse
Set tSC=..Adapter.SendFormDataArray(.tHttpResponse,"POST", ..%HttpRequest, "", "", tURL) 

// Validate that the call succeeded and returned a response. If not, throw error.
If $$$ISERR(tSC)&&$IsObject(tHttpResponse)&&$IsObject(tHttpResponse.Data)&&tHttpResponse.Data.Size 
Set tSC = $$$ERROR($$$EnsErrGeneral,$$$StatusDisplayString(tSC)_":"_tHttpResponse.Data.Read())
Quit:$$$ISERR(tSC) If $IsObject(tHttpResponse)

// Instantiate the response object
pResponse = ##class(MyCustomMessageClass.Vendor.Response.GetBearerToken).%New()
// Convert JSON Response Payload into a Response Object
tSC = pResponse.%JSONImport(tHttpResponse.Data)
Catch {
// If error anywhere in the process not caught previously, throw error here.
Set tSC = $$$SystemError
Quit tSC

We had this exact scenario a year ago or so and the easiest solution for us, since we aren't using System Default Settings like Eduard mentioned,  was to open up the production class in Studio and do a search/replace (Ctrl-H)

Search for: epicsup

Replace with epictst

Then save/compile. Note will take effect immediately (edit: trying to recall if we had to click the 'Update' button in the Production Monitor for the connections to disconnect from the old and reconnect to the new. Definitely verify in your production monitor that the connections established to their new destination.)

For anyone reading this in the future, this was acknowledged as a bug by the WRC - devchange JGM926. Scheduled for 2020.2 release (subject to change.)

Simple workaround, pointed out by Gertjan's answer, is to store the value to a local variable and use the local variable in the case statement.

From your screenshot, I see you're using a custom message class ORMFARM.amplitudeHTTPRequest. Have you extended the class to include  Ens.Request? 

I recently had a similar project and to get the request and response message bodies to show in trace, I had to include Ens.Request and Ens.Response (respectively) in my class definition:

Class MyRequestClassExample Extends (Ens.Request, Ens.Util.MessageBodyMethods, %JSON.Adaptor)


Property Example As %String;


Good morning Eric -

The logical operator for OR in a DTL is a double pipe - || - whereas an AND is a double ampersand - &&.

See: http://oairsintp.ssfhs.org:57772/csp/docbook/DocBook.UI.Page.cls?KEY=TCOS_Logical

So in your case, I'd recommend an IF/ELSE block 

IF source.PROP45 = "whatever" || source.PROP45 = "whateverelse"

set target.{PD1.AdvanceDirectiveCode(1).identifierST}     trueoption


set target.{PD1.AdvanceDirectiveCode(1).identifierST}      falseoption

There are also some built in functions the DTL editor provides to do it all in one line. It comes down to preference on readability, in my opinion. 

EDIT - here's an example using the AND operator in the DTL (&&) but in much the same way, you could use an OR (||) operator.