Sure, that's default behavior.
- Log in to post comments
Sure, that's default behavior.
Custom queries can be used. Check the examples there. Or you can just iterate over data global and call %OpenId.
To get user/pass? Sure:
set sc = #class(Ens.Config.Credentials).GetCredentialsObj(.cred, "caller.class", "Ens.Config.Credentials", "CredentialsId") write cred.Username write cred.PasswordGet()
Are long strings enabled?
I'd start without base64 decode just to check how ftp works.
I think this would be enough to work (1st argument in Store is a full filename and second is a stream you want to put there):
ClassMethod DecodeBase64HL7ToFileFaxing(base64 As %Stream.GlobalBinary, Ancillary As %String, FileName As %String) As %String
{
set ftp=##class(%Net.FtpSession).%New()
if 'ftp.Connect("xxxxx","xxxxx","xxxxxx") $$$LOGINFO("Unable to connect to inteng11")
if 'ftp.Store(FileName, base64) $$$LOGINFO("Unable to write file")
if 'ftp.Logout() $$$LOGINFO("Failed to logout")
quit $$$OK
}It looks more like column-level security.
If you have Ensemble production defined you can call BS or BO from Cache ObjectScript using testing service.
Or you can just use %Net.FtpSession object to store stream on a remote server.
That error can be removed by setting MANAGEDEXTENT class parameter to 0 as Extent Manager would stop tracking globals for that class.
You'll need:
I used this kit, it has a lot of additional parts for starter projects.
I've also done user user authentication in Caché using RFID cards.
Cool!
Currently all the classes are in one folder (and as there's 6 classes currently, that's ok), but is there any reason not to separate them further into folders by package?
3. CSP Debugging
Does it include REST debugging?
Awesome!
Check method reports 19.
I think you need to call:
Do UpdClsDef^%occLibrary("ITPlanet.Task2")before compile.
Fixed that
Here's how you can define your own errors.
Create messages.xml with your error messages:
<?xml version="1.0" encoding="UTF-8"?>
<MsgFile Language="en">
<MsgDomain Domain="asd">
<Message Id="-1" Name="ErrorName1">Your error 1</Message>
<Message Id="-2" Name="ErrorName2">Some other error 2 %1 %2</Message>
</MsgDomain>
</MsgFile>Import it into Cache:
do ##class(%MessageDictionary).Import("messages.xml")It will result in two globals being populated:
USER>zw ^CacheMsg
^CacheMsg("asd","ru",-2)="Some other error 2"
^CacheMsg("asd","ru",-1)="Your error 1"USER>zw ^CacheMsgNames
^CacheMsgNames("asd",-2)="ErrorName2"
^CacheMsgNames("asd",-1)="ErrorName1"Next we generate CustomErrors include file (docs):
USER>Do ##class(%MessageDictionary).GenerateInclude("CustomErrors",,"asd",1)
Generating CustomErrors.INC ...Here's what CustomErrors.inc looks like:
#define asdErrorName2 "<asd>-2" #define asdErrorName1 "<asd>-1"
Now we can use new custom errors:
Include CustomErrors
Class demo.test [ Abstract ]
{
ClassMethod test(A As %Integer) As %Status
{
if A=1 Quit $$$ERROR($$$asdErrorName1)
if A=2 Quit $$$ERROR($$$asdErrorName2,"f","6")
Quit $$$OK
}
}Results in:
USER>d $system.OBJ.DisplayError(##class(demo.test).test(1)) ERROR <asd>-1: Your error 1 USER>d $system.OBJ.DisplayError(##class(demo.test).test(2)) ERROR <asd>-2: Some other error 2 f 6
Text is not mine, translated from here.
Here's a very simple Ensemble REST service. That said, I recommend usual %CSP.REST broker with calls to Ensemble via Ens.Director:CreateBusinessService. Check Demo.ZenService.Zen.WeatherReportForm class, GetWeatherReport method in ENSDEMO namespace for an example.
Check %ZEN.Auxiliary.altJSONProvider class, %UnpackObjectToCOSObjectmethod, it converts dynamic object to the specified class.
Set dynamicObject = {}.%FromJSON(%request.Content)
Set object = ##class(%ZEN.Auxiliary.altJSONProvider).%UnpackObjectToCOSObject(dynamicObject, "class")Compare "Enabled ciphersuites" property in your SSL/TLS configuration.
But you'll probably need a longer key.
Some convenience macros for SQL types are defined in EnsSQLTypes.INC.
They are stored as objects of Ens.Config.DefaultSettings class.
You can:
If you store data in globals, you can run parallel jobs on your data.
On a single job however, locals are faster because there's no journaling and disk writes.
%OnAddToSaveSet() can get called many times during modification or saving of our target object and all objects related to it. Therefore it's better to move code we need to execute once to triggers or initialexpression or sqlcomputed.
Please note that It's not recommended to use %OnAddToSaveSet(), especially performing heavy operations there.
zip ≠ gzip
Like this:
set p = ##class(%SYS.ProcessQuery).%OpenId($job)
set p.UserInfo = "My Text"
kill pI thought there's maybe some special keyword.
Thank you, Amir!