No question. I've changed the type to article now.

Thank you Tony.

This would mean that the password change service will have to be on a CSP application configuration which is unauthenticated by the underlying Cache web-service handler.

Another option may be to let the password never expire and perform peer certificate verification by issuing a certificate to the client and verifying it during the SSL/TLS handshake.
Is this possible in Cache on the CSP gateway in some way, on a User level or even on a CSP application configuration?

Thank you. This is very informative.

There are no transformations.

I create a new message and call an Operation using ProcessAsync in the Business Service. This message has a property for the File Name which I want to populate. with the name of the original file picked up by the business service.

Thank you. The parameter of OnProcessInput being a %Stream.Object confused me, as that has no FileName property in the class reference. The FileName property did however work. I realize now that a FileCharacterStream object is passed to the OnProcessInput from the File InboundAdapter.

Regarding your question: I use the original file name in a Business Operation, which uses the File.OutboundAdapter. I concatenate a suffix to the original filename and then use putline of the OutboundAdapter to create the file.

Thank you. If it was possible to up-mark the answer more than once, I would have done it.

There is a difference in the values created by Cache and by OpenSSL

I've created a config file from some random example and placed it in the bin directory. I can run it from there in the command prompt, but the $zf does not execute it.

Would you mind sharing your openssl config file and where it should reside? Which paths should be configured on Windows?

Will the user require the %CallOut service to be available to do this on a locked down install(production environment)

I need to have the newlines in. The only reason why files are used, is because Cache does not support the RSA PSS padding required to sign the web-service messages I need to send. I then write what needs to be signed to a file and use opensl to sign it.

The value that needs to be signed is:
X-Date:CurrentDate\r\n
x-Client-Key:KeyValue\r\n
MessageBody

See: https://community.intersystems.com/post/sha256-signing-rsa-pss-padding

So it builds up the file to sign using the values and $char(13,10).
Then signs it using SHA256 and RSA PSS padding into a new file.
The contents of the new file is then base64 encoded.
The base64 encoded value is then sent together with the file contents, date and Client Key.

This works on Windows, hence the question about openssl and the newlines.

Is the base64 encoding a possivle culprit?

When writing to the filecharacterstream, I use Write and not Writeline, as the string is built up with the newlines and I use $char(13,10) specifically.

I just compared the files between Windows and Solaris, and the Solaris files are two bytes smaller - so probably the \r($c(13)) getting dropped.

It seems like %Stream.FileCharacter does not use the LineTerminator that was set in the output file. Even when using Write and adding $char(13,10), it converts it to the OS setting.

I resolved this line terminator issue by using %Stream.FileBinary and converting my data to UTF8 prior to writing it to the binary stream.

Thank you. I am considering option 3, it is a learning curve, as I'do not have any experience in cloud computing.

I am considering Azure, as it is is the only cloud provider with servers in our country and on the continent. Any guidance as to which package/product to use on Azure?

Thanks. I've figured that much out. I just don't know which Azure product. I will create a trial/test account with them and play around with ICM and see what happens - that should answer many of my questions/concerns. If successful, I will attempt to create an article and post it on the community.

The repo contains an example. Here is an example of exporting the stack to a string in terminal

DEV>set sc = ##class(Examples.DebugStack).TestDebugStack()
Examples.DebugStack     TestDebugStack  Calling Method InnerStackTest with value: 5
|  |- Examples.DebugStack       TestInnterStack pVal argument: 5
|  |- Examples.DebugStack       TestInnterStack tMyVal: 15
|  |- Examples.DebugStack       TestInnterStack Calling TestThirdLevelStack with tMyVal: 15
|  |  |- Examples.DebugStack    TestThirdLevelStack     pVal argument: 15
|  |  |- Examples.DebugStack    TestThirdLevelStack     tFinalVal: 35
|  |- Examples.DebugStack       TestInnterStack TestThirdLevelStack completed OK
Examples.DebugStack     TestDebugStack  TestInnerStack completed OK
 
DEV>

It will be more readable if placed in a text file or a CSV. The "columns" are tab delimited.

It has the option of providing output to a string or a global character stream.

Hi Evgeny,

Thank you for the suggestion.

We still then need to keep on developing primarily on Ensemble and once we release, then we create a release file for IRIS, which sounds good. This does create the risk of testing something on Ensemble and it maybe does not work on IRIS.

Every project has its own set of classes as well in addition to the shared code libraries. On these project specific classes, we may want to use new IRIS features. This creates the issue that I can't develop on Ensemble and only build and IRIS release. Not sure if you understand what I am getting at. The idea was that if a dev works on one of these projects, he/she only changes the server connection in Atelier, synchronise, compile and work. If that person needs to work on another project on Ensemble, the repeats the steps above. The git repo takes care of the source management, even though we are on different InterSystems products.

We use a local git repository on one of our servers.