User Answers

Sebastien,

I remember once customer had the same problem and it turned out that they had large amount of cached queries existent in that namespace.

Can you check and eventually delete them? 

Other than this, I can imagine some issues with source control if you have any, but this is just a guess.

HTH

Dan

Zdenek, following up with our offline conversation, I made small change to my installer manifest, so PerformUpgrade() method contains something like this:

    s ^dk="Upgrade to version "_..#VERSION_" performed OK"
    s ^dk("aux")=pAux

So, at the end I found the answer and I'm going to share it with the audience, in case someone may have the same issue.

But before I provide code, a few more words about SOAP service. 

The SOAP service has just one  method - Test. It accepts a string and returns another string. That's it. I then created a WS Policy via Wizard, this policy is using SAML Authorization with X.509 Certificates. (no ws addressing,  no body / token protection, and recipient token using X.509 credentials to keep my example simple)

Hello Muhammad,

first of all, I'm not able to give you a complete answer, but hope to have some thoughts that may help you.

Hello Julie,

AFAIK there is no intelligence in operation's message queue other than First came - first served.

You need to build the logic yourself. Having separate operations for large and small messages / priorities is a good starting point. You can then use poolSize setting to play with priority of processing (bigger poolSize means "usually" larger throughput.)

Dan

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:

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

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, ...

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

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.