Hello Padma,

sorry for delay in answering, I'm on vacation with limited access to computer. Glad you have resolved the issue!

I was wondering what exactly are you trying to achieve, as grant type is determining messages flow between client and OAuth2 server. The way you authenticate yourself against Cache CSP (client) application is not related to the grant type at all. You can set your client CSP/ZEN app to use any Cache authentication. In one of project, where a Cache is issuing a HTTP request to a OAuth2 protected resource I'm using this code for password type grant:

… main code

    try {
        set pResponse=##class(User.Response).%New()
        set tHttpRequest=##class(%Net.HttpRequest).%New()
        $$$THROWONERROR(tSC,..GetAccessToken())                
        $$$THROWONERROR(tSC,##class(%SYS.OAuth2.AccessToken).AddAccessToken(tHttpRequest,,tSSLConfig,..#oAUTH2aPPnAME,"NOTCSP"))   // hardcoded sessionid to NOTCSP

        set tHttpRequest.Server=<server>
        set tHttpRequest.SSLCheckServerIdentity=0
        
        set tURL=<whatever URL points to the resource>
        $$$THROWONERROR(tSC,tHttpRequest.Get(tURL))
        #dim tHttpResponse as %Net.HttpResponse = tHttpRequest.HttpResponse

        $$$THROWONERROR(tSC,pResponse.Content.CopyFrom(tHttpResponse.Data))        
      } catch (e) {
       Set tSC=e.AsStatus()
   }

   and GetAccessToken method

Method GetAccessToken() As %Status
{
    #dim tSC as %Status = $$$OK
    try {
        //obtain Oauth2 token
        set tScope="user/*"
        set tApplication=..#oAUTH2aPPnAME
        set tSessionId="NOTCSP"
        set tUsername=<username>
        set tPassword=<password>
        
        #dim tError as %OAuth2.Error
   
        
        // verify we have already access token
        if '##class(%SYS.OAuth2.AccessToken).IsAuthorized(tApplication,tSessionId,tScope,.tAccessToken,.tIdToken,.tResponseProperties,.tError) {
            // we shall check whether we have access privileges, not done here
            //eventuallyt call ##class(%SYS.OAuth2.Validation).ValidateJWT()            
            
            // retrieve token from auth server and store to internal peristent store
            $$$THROWONERROR(tSC,##class(%SYS.OAuth2.Authorization).GetAccessTokenPassword(tApplication,tUsername,tPassword,tScope,.tResponseProperties,.tError))
            // load token to memory
            set tIsAuthorized=##class(%SYS.OAuth2.AccessToken).IsAuthorized(tApplication,tSessionId,tScope,.tAccessToken,.tIdToken,.tResponseProperties,.tError)
        }
        if $isobject(tError) throw
     } catch (e) {
        throw e
    }
    Quit tSC
}

Soufiane,

supposing you have successfully been able to add the token to your client (this depends on ate respective framework) call for Cache resources (via REST API), then on Cache side, if that's where your data (resources) are sitting, you can use something like this:

set accessToken=##class(%SYS.OAuth2.AccessToken).GetAccessTokenFromRequest(.tSC)  
   // decode token data into JSON object
   $$$THROWONERROR(tSC,##class(%SYS.OAuth2.AccessToken).GetIntrospection($$$APP,accessToken,.jsonObjectAT))
   /* service specific check */
   // check whether the request is asking for proper scope for this service
   if '(jsonObjectAT.scope["special-deals") set reason=..#HTTP404NOTFOUND throw
      
   /* finally */
   // validate signed access token (JWT)
   if '(##class(%SYS.OAuth2.Validation).ValidateJWT($$$APP,accessToken,,,.jsonObjectJWT,.securityParameters,.tSC)) {
    set reason=..#HTTP401UNAUTHORIZED
    $$$ThrowOnError(tSC)
   }
 
perhaps you shall try to look at this post - https://community.intersystems.com/post/angular-client-demo-using-oauth2-authorization-server-protect-caché-based-resources, it also contains a link to the angular based project and contains implementation of sample Cache REST service.
 
Dan

Soufiane,

briefly, perhaps not 100% correctly - use Google for more details, claims are characteristics provided by OIDC (OpenID Connect) server that describe authenticated user. e.g. Caché by default supports these claims (and more):

preferred_username, email, email_verified, name, phone_number, phone_number_verified, iss, sub, aud, exp, auth_time, ...

claims can be used by the access_token to provide additional information about the user passed to the resource server when calling REST method. Some claims are mandatory, some are optional. You can provide optional claims by the SetClaimValue() method.

Dan

Hi Praveen,

this is not going to be an exhausting answer but rather a summary of choices you have.

First thing to answer: are you working with a legacy application, that stored data in globals, not using our Cache persistent classes? In this case, you would like to follow Sean's globals to classes mapping guide.

Another option, suitable in cases where you have a mix of persistent classes and only some data stored directly in globals, you may consider using custom SQL queries. In such query you implement code that iterates over your global nodes and expose result as SQL resultset. You can then call query as a standard stored procedure. see Cache online reference for mode details here.

There is one more option too, which could be used in some special cases when global is a simple structure. In such case you could create a new persistent class definition and simply override the storage generated during its compilation to reflect your global structure. This is less flexible than using SQL mapping mentioned as first choice, but could be easier for you.

HTH

there is an easy solution to your issue. Simply use a Cache Task Manager. Create a new task, and within code, instantiate Ensemble service Ens.Director,

e.g.

Set tSC=##class(Ens.Director).CreateBusinessService("your service configration name",.tService)

If ($$$ISERR(tSC)) Quit
Set tSC=tService.ProcessInput(%request,.output)
If ($$$ISERR(tSC)) Quit
If $IsObject($G(output)) {

   // do whatever you want here

}

Noone would give you exact numbers. It really depends on your use case.

However, adding 200 properties to an Ensemble message (not considering other classes as you pass just messages) may either simp0ly mean that you add 200 properties to ONE class or to MANY classes, depending how clever the original design of your production was.

You may, or with the same probability many not, need to change the message design and switch to virtual documents ... it really depends on many factors unique to your particular use case - throughput expected, load of data incoming etc etc... 

Jose, $lb() holds STORED values of you object instance. If your opened instance modified property(ies) then I see no point of looking into stored data, just serialize you IN-MEMORY values to JSON.

On the other hand, if a process A opened and modified instance of the object and without saving and you want to serialize the same instance from process B, then again, there is no difference between opening an object instance or using some custom serialization directly from stored data.

It is not good practice anyway to keep objects opened for a long time without saving their new values.

lastly, my comment about JSON array was that JSON array doesn't need to know the name in the name:value pair so you can easily write a custom JSON serializer to serialize directly $lb() into JSON array.

 

 

maybe I missed your original business case need, can you explain why current implementation is not good enough for you?