Hi Craig,

sry for the late response. Thank you this is what I was already thinking about. I´ve did some tests and the approach works for me. I´ve marked your as accepted.

Anyway I´am still highly interessted in InterSystems point of view on this.

best regards,

sebastian

Hi Craig,

thank you for your response. So first of all good to hear that I am not the only one with this kind of questions. I assume you don´t configured an OAuth Client via SMP directly but instead do the  invocation of the API endpoint to get the token directly in the operation - therefore you should not use any %OAuth... framework-functionalities from within the operation - am I correct?

It would be very interesting to here from InterSystems what would be the best practise here. Anyway this should work. Could you supply me with an example of how you implemented the GetBearerToken() method?

best regards,

sebastian

Thank you for that hint. Adding the xml schema definition to the studio-project would make transport to other system stages a lot more easier. One don´t need to remember where schemas are stored and doesn´t need to to organize schemas in seperated files floating around the file system. I guess I´ll end up adding the EnsEDI.XML.Schema global to my studio project. Thanks again for that hint.

Hi Robert,

my intention was to add the imported xsd schema to a studio project. However, I didn´t generated any classes explicitly. I´ve just imported a xsd schema in the management portal and expected (wich works fine) but expected to have xsd-schema availabe in studio just like with hl7-schema (*.HL7). So I guess there is no way for doing that directly and therefore I need to place the schema file in mit default csp location to be able to add it to a studio project. I see no other way to be able to have that schema to be available for comparision (diff).

kind regards,

sebastian

Hi Eduard,

already did this. the role %Developer should already include the %EnsRole ressources. Even assigning them to the created role manually gives me that error when logging in. Somehow as part of the login procedure, the cachelib db is accessed. Even if granting the ressources of cachelib the error remains.

kind regards,

sebastian

If you are running Ensemble or HealthShare you may have a look at Ens.Util.Time or Ens.DataType.UTC. They provide an API to work with different time formats and also theire conversions. In Ens.DataType.UTC there is a method timeLocaltoUTC pass in you value and you don´t have to worry about.

Thank you Eduard for the fast response on my questions. This totaly meets my usecase.

Best regards,

Sebastian

Hi,

as my advisor told me. This is a bug in Ensemble/Caché release 2017.2.2 since the intended behaviour to set sqltablename on serverside is sufficient and this specific security consideration reported a "false positive" - if I got it right a correction for this is available with ensemle 2018.1 and is identified as SAM524. The current workaround is to use both approaches setting tablename on the server and use permitclientsql = "true".

Anyway I´ll mark this issue here as solved/answered.

Best regards,

Sebastian

Hi,

after talking to WRC and some testing. The approach altering the ZEN tablePane, tableName on the server as depicted above works until 2017.1.2. From 2017.2.1 it seems to be reqiured to have an additional property for the tablePane to be set. This property is calles ´permitClientSQL´ (set to true). This isn´t well documented in my opinion and the behaviour is to weaken the security. But even when set to true this property still requires to have the tableName property on the server despite documentation says something different.

They´ll have a look at it, since my advior himself wasn´t quite sure what that change between 2017.1 and 2017.2 is about. Keep you update when I´ve got some new details.

best regards,

sebastian