This approach has an advantage over usign %GSIZE as the query in %SYS.GlobalQuery class has a parameter that can make quick estimations of the global sizes (simply counting # of blocks occupied by globals) rather than potentialy very slow exact global size determination always used by %GSIZE 

Actually, advices given in other answer are quitec contradicting, one says install glassfish whilst other says uninstall glassfish.

Why is Atelier at all trying to use glassfish?

Thank you Alexander,

I tried to search community for this error but apparently I did not use correct keywords as I could not find previous posts with this very problem.

At least we have a workaround as explained in links you provided.



are there any plans to port it to Angular2+ ? e.g. connecting to ngx-charts?




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
   /* 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
perhaps you shall try to look at this post -é-based-resources, it also contains a link to the angular based project and contains implementation of sample Cache REST service.

I think grant types are not used by he resource server, only by Confidential and Public clients.


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.


Evgeny, consider using OAuth2 with OpenID Connect as the first choice.


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.