I'm not that familiar with adapters, but the documentation suggests that you need to use the SkipBodyAttrs property to send a header like Content-Type. Also, I think you need to decide whether you're sending form data or a body. When tFormVar is "Content-Type,apikey", the documentation says that your third data argument will be assigned to the last form variable, apikey, which is almost certainly not what you want. Your second try with three variables looks more likely to work, depending on what the service expects in the body.

I don't know anything about the duplicate apikey. That's presumably specific to the service you're calling.

I would use the InsertFormData() method on the HttpRequest object. There's an example in the class reference:

https://docs.intersystems.com/latest/csp/documatic/%25CSP.Documatic.cls

I'm finding it hard to read the output images, but every one of the commands that you listed has a Docker option after the image name. The form of the command should be:

    docker run <Docker opts> image_name <IRIS args>

To be clear, the -e (--env), -p (--publish), and -v (--volume) switches are Docker options; they go before the image name. The --key and --before switches are IRIS arguments; they go after the image name.

You're sort of back to where you were before, with Docker switches occurring after the image name, although you now have the image name in there twice. I don't have your environment, so I can't test this exact command, but I think you want something like this:

    docker run -d --privileged -v /nfs/IRIS:/IRIS \
    --env ISC_DATA_DIRECTORY=/IRIS/iconfig \
    --env ICM_SENTINEL_DIR=/license \
    -p 52774:52774 --name IRIS4 efca5c59cbb7 \
    --key /IRIS/iris.key ...

If you're still having trouble, back up and build the command line incrementally. Start simple:

    docker run -d --name IRIS4 efca5c59cbb7

Then add in your Docker switches (-v, -e, -p, etc.), and finally add in the IRIS arguments (--key, etc.). That way you can tell which switch or argument is causing a problem.

It looks like you're trying to run an image identified as efca5c59cbb7, but in this segment of the command line, iris is taken as the image name:

    --env ICM_SENTINEL_DIR=/license iris

I don't think that your test method is being run. I'm pretty sure that it has to start with "Test" (with a capital "T") for the manager to discover it.

You've set the TranslateTable for both stream and tNewStream to "cp1252". If the input file is UTF-8, then stream.TranslateTable should be "UTF8". Otherwise, each UTF-8 code unit (i.e., byte) is read in separately as a CP1252 character.

Apart from just redirecting to a file, and then reading from that file, the closest you can get is to use a command pipe device:

https://docs.intersystems.com/irislatest/csp/docbook/DocBook.UI.Page.cls...

The main drawback, relative to $zf(-1) or $zf(-100), has been that you couldn't get the exit status of the command. I think that is now possible, but I'm not sure offhand in what versions.

Note that command pipes are not supported in Cache for VMS.

Your code creates a property when getting the property returns a 404. However, I'm getting a 400 when a property doesn't exist:

$ curl --user _system:SYS -w "\n***\n%{http_code}\n" 'http://127.0.0.1:52773/api/docdb/v1/DEMO/prop/DEMO.TEST11/Ergebniszuf'
{"status":{"errors":[{"error":"ERROR #25541: DocDB Property 'Ergebniszuf' does not exist in 'Demo.TEST11'","code":25541,"domain":"%ObjectErrors","id":"DocumentDatabasePropertyNotValid","params":["Demo.TEST11","Ergebniszuf"]}],"summary":"ERROR #25541: DocDB Property 'Ergebniszuf' does not exist in 'Demo.TEST11'"},"content":null}
***
400

Compared to a delimited string, lists have the overhead of storing the length of each element, typically one extra byte. Numbers and Unicode characters are also stored differently, sometimes more efficiently, sometimes less. Otherwise, there is no difference between fetching a delimited string or a list.

The DataBlkRd and DataBlkBuf columns shows that ^StringGlobal was read entirely from global buffers, whereas ^ListGlobal had to read over 9,000 blocks. In each case, it seems that the global occupies about 17,000 blocks; about 136 MB, assuming 8 KB blocks.

I suggest that you do the following:

• configure 256 MB or more of global buffers
• restart the instance
• run one of the tests twice
• restart the instance
• run the other test twice

Based on your numbers, the first runs will be cold, and should take a minute or two. The second runs should be essentially instantaneous.

When you call %ToJSON() in a DO context, it writes to the current device, which should not cause a MAXSTRING error. However, due to an interaction with I/O redirection, you should preface the call with WRITE "":

write ""
do specimenArray.%ToJSON()

This may be fixed in recent versions.

Yes. Use the SYS.Database class to create a .DAT file, Config.Databases to create a database definition (what we used to call a dataset), and Config.Namespaces to create a namespace. These are all in %SYS, so you'll need the appropriate privileges.

You should create properties for keys that you want to query. Take a look at this section in the online documentation:

https://docs.intersystems.com/irislatest/csp/docbook/DocBook.UI.Page.cls...

Also, there is a brief description in the reference for the %DocDB.Database class:

http://localhost:52773/csp/documatic/%25CSP.Documatic.cls

For example:

USER>s db=$system.DocDB.CreateDatabase("Fitabase1")

USER>w db.%CreateProperty("TotalSteps","%Integer","$.TotalSteps")
2@%DocDB.Database

Now the ISC.DM.Fitabase1 class (or whatever your generated class is) has a TotalSteps property. If you already have data, you need to populate the associated index. A quick and dirty way to do this is an SQL query like the following:

update ISC_DM.Fitabase1 set %Doc = %Doc

I'm not that familiar with DeepSee / Analytics, but the output of %CreateDatabase() and %CreateProperty() is a standard persistent class.

I encourage you to get in touch with the WRC, but if you post more information, we might be able to make some progress. For starters, what version of Caché and Python, and what kind of errors are you seeing?

I successfully built the binding using the following:

• macOS 10.12.6 (Sierra)
• Python 2.7.10 (built-in version)
• command line tools for Xcode 8.3.3
• Cache 2017.2.1 build 801U

It looks like I got a total of eleven compiler warnings.

As described here, it's a bit tricky to actually use the binding with the system version of Python due to Apple's System Integrity Protection (SIP):

https://community.intersystems.com/post/installing-intersystems-python-b...

This may be fixable with some install_name_tool surgery, but a separate installation is recommended.

Take a look at the WebServer setting in the portal at Configuration > Additional Settings > Startup:

http://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=...

This changes the WebServer entry in the [Startup] section of cache.cpf.

I notice two things:

1. The C# ciphertext is 64 bytes, which is twice as long as I'd expect for a 31-byte input.
2. In the first sixteen bytes of the C# ciphertext, alternating bytes are NUL.

I thought maybe C# is using UTF-16, but I I haven't managed to replicate its output using $zconvert with "UnicodeLittle" or "UnicodeBig".

Edit: the first sixteen bytes of the output appear to be the first eight bytes of the initialization vector converted to Base-64, then UTF-16.

For the most part, dynamic objects use local memory that is accounted for by $zstorage and $storage. However, some of it comes from other heap-allocated memory, similar to long strings. You can round trip a large JSON object through a dynamic object with %FromJSON()/%ToJSON(), even if an individual field exceeds the string limit. However, it is not currently possible to get the value of such a field within Caché.

Note that you should call %ToJSON() such that it outputs to a device or writes to a stream:

USER>d o.%ToJSON(stream)

USER>d o.%ToJSON()

Otherwise, you may get a STRINGSTACK error:

USER>w o.%ToJSON()

W o.%ToJSON()
^
<STRINGSTACK>

Are you sure that this problem is due to endian? A byte stream does not in itself have a byte order; multi-byte data structures do, such as Unicode characters encoded as UTF-16. As for the signature itself, I would expect its encoding to be specified in a portable manner.

Is it possible that line endings are getting changed?

This method probably first shipped with Caché 4.0 in December 2000, but the oldest instance I have handy is Caché 4.0.4:

USER>w $system.Version.GetMajor()
4

I don't really understand the question. It sounds like you're trying to convert from one eight-bit character set to another, but French generally uses the same character set as English, as far as I know. If you're using a Unicode instance of Caché, your first resort should be I/O translation: translate the input to Unicode, then translate on output to the desired character set. Doing it in COS is slower and less convenient.

That said, here are some things in your code that don't really make sense:

1. a."i"; should probably be a.%Get(i).
2. a-128; maybe a.%Get(c-128)?
3. I don't understand the purpose of the first loop or the return statements.
4. value(j); ...?

If I were to hazard a guess at rewriting this, my first try might be something like this:

for i=1:1:$l(str) {
    s c=$e(str,i)
    if $a(c)<128) {
        w c
    } else {
        w $c(a.%Get($a(c)-128))
    }
}