go to post Craig Regester · Mar 4, 2020 In our research with the security team and Windows server team, the advisory indicates that there are additional options provided to require the TLS/SSL bind but it is not automatically turned on for existing servers. The InterSystems advisory above (and what was sent out via email) makes it sound like this will cause immediate failure on all existing configurations, but that doesn't appear to be the case after review. Is this correct? We are based on AIX 7.2 so the other challenge is that we use a round-robin DNS hostname to access the AD LDAP servers (ldap.ourdomain.example) but the certs for the servers the round-robin passes off to are 3 different servers. InterSystems only provides a single field for a PEM cert. Will it accept a concatenated PEM cert containing the info for all three servers? We have had to use this approach previously for Java keystores authenticating through LDAP.
go to post Craig Regester · Jan 15, 2020 Does it need to be the 16.1 (or greater) XL C fileset (we have a lesser installed)? And just the runtime or the compilation as well? Verifying for our systems' guys.
go to post Craig Regester · Nov 15, 2019 Appreciate the response but what I'm looking to do is convert RTF to PDF and then base64 encode it.
go to post Craig Regester · Nov 15, 2019 Has anyone had success using this or a similar solution running Health Connect/HealthShare on an AIX 7.2 platform? LibreOffice does not provide AIX-specific packages.
go to post Craig Regester · Oct 30, 2019 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 ELSE 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.
go to post Craig Regester · Sep 30, 2019 Thanks Nicholai! I swear I tried this in some iteration (I've re-written this a dozen different ways it feels like) but if it's working for you, clearly I haven't! I'll give it a go and mark your answer as accepted once successful. Appreciate it! Edit: Yep it worked. Knew it was something simple. Thanks again.
go to post Craig Regester · Feb 21, 2018 Good morning - I reported this issue when we installed 2017.1.0 last summer.They recently addressed it in 2017.1.2 (released in Nov 2017 I think?):http://docs.intersystems.com/documentation/cache/releasenotes/201712/rel...Summary: Ensure All Matching Results Appear in Message ViewerDescription:In the Message Viewer, users can filter the results which will be displayed by various criteria. However, when the search criteria included certain extended criteria and the selected Page Size was smaller than the total number of messages, some of the matching results were not displayed even if you navigated to the next page. This change ensures that all matching messages are displayed.We updated our environments to 2017.1.2 and this issue no longer occurs.Hope this helps!-Craig
go to post Craig Regester · Jan 10, 2018 While not truly extending Ens.Util.LookupTable, we have numerous cases where we have to handle multiple values against a single key. Our solution was to identify a special character we would use as a delimiter of values (say @ for instance) and store them as such: value1@value2We then have a custom CoS function that we can use to perform the normal lookup functions that parses the values and returns them as an array object that we can then use to pull out the value we need.If you are simply after a pair of values, then the CoS is not even needed as you could use the built-in Piece function to rip apart the values using the delimiter.
go to post Craig Regester · Nov 16, 2017 Not sure if your issue is the same I ran into when I got this error, but to solve I did the following:1. In the Eclipse installer, click the 'Network' button (it's next to the ? Help button in the lower tool bar.)2. Make sure your Active Provider setting is set to Direct. By default, the installer was set to Manual I think and after I changed to Direct, I was able to read the repository.
go to post Craig Regester · Oct 19, 2017 Thanks Robert, I understand. I ended up solving this another way anyway... I realized I did not have my REST Dispatch Web App sharing the same cookies path as my main web app so even though I was logging in with authorized credentials that should have no problem running this query, when I tried to execute it via REST I passed into another 'cookie domain' and lost the authorization header.Once I fixed that setting, it works just fine for the users it should and I don't have to grant Unknown User elevated privileges, which is ideal. Thanks again!
go to post Craig Regester · Oct 17, 2017 Thanks for your answer, Robert. I had considered the option of using a 'Privileged Application' and after your post, have started down that path but that still leaves open my original question...How do I determine what resource/privilege is required to execute this query? %Developer does not work. Is there documentation I'm missing in the API reference or elsewhere that indicates the necessary permissions needed to make certain calls? I only wish to grant the minimum necessary but right now, only %All makes it work. Is there some sort of debug I can use to see what role it's running a $SYSTEM.Security.Check on when it tries to execute this query?
go to post Craig Regester · Aug 30, 2017 Awesome, this is exactly what I was looking for! Thank you. I was getting close with %Get and the iterator but wasn't quite making the connection with the whole line.LineNumber part. Thanks!!!
go to post Craig Regester · Aug 30, 2017 Thanks for your answer as well! This is actually what we were already doing with 2015.1 when handling JSON. So moving into 2017.1, I was hoping to make more use of the built-in JSON handlers because the JSON response I posted was a rather simple one - some of our more complex responses has our string manipulations getting quite long-in-the-tooth.
