You can store salt in the same table, it should just be unique (autogenerated) for each password.

There's a good explanation why that's enough, here.

Do not store passwords.

Store password hashes + Unique salt. When entered hash

Check $system.Encryption class for various hashing algorithms.

The only case where you need to store passwords is when they are used to authenticate Cache server against external systems.

In that case use the same $system.Encryption class to encrypt them for storage.

we're talking of 200-300+ passwords here.

Per user?

Is the "bi login" hosted on the same Cache server?

If so you'll need to add /dsw and /mdx2json to the same group/same cookie path as your app and you should be all set.

Please mark Stefan's answer as accepted.

You could (and probably should) separate these parts of routines as separate methods or at least subroutines.

And if you don't have labels, adding them wouldn't break existing code.

For example you have this routine:

TEST
    write 1
    write 2
    write 3
    quit

It, when called would output

>do ^TEST
123

If you then add a label somewhere:

TEST
    write 1

MYLABEL
    write 2
    write 3
    quit

The routine would wok the same on previous calls:

>do ^TEST
123

But you'll also be able to call only the label:

>do MYLABEL^TEST
23

Can you ballpark the workload?

If it's not too big, I think the easiest solution would be just writing ObjectScript method that calculates what you need.

Thank you!

tFullValue should be always equal to tNumber regardless of tNumber value.

write $l(2.1)

>3

I'm curious about this

set tFullValue = $EXTRACT(tNumber,1,$length(tNumber))

in what cases tFullValue is not equal to tNumber?

Also after 2014 you can use * to denote last char like this:

set tFullValue = $EXTRACT(tNumber,1,*)

Do you want the data to be accessible by anyone who can view the page?

There's no default function to do it, but you can easily develop your own custom function. There's $IsValidNum ObjectScript function, which could be used to check that variable is a number. So something like this should work:

/// Functions to use in rule definitions.
Class Custom.Functions Extends Ens.Rule.FunctionSet
{

/// Returns 1 if a string is a number, 0 otherwise
ClassMethod IsValidNumber(string As %String) As %Boolean [ CodeMode = expression, Final ]
{
$ISVALIDNUM(string)
}

}

SendRequestAsync is available in all Ensemble Hosts (Services, Operations, Processes).

For Operations and Services the signature is:

Method SendRequestAsync(pTargetDispatchName As %String, pRequest As %Library.Persistent, pDescription As %String = "") As %Status

And for Processes the signature is:

Method SendRequestAsync(pTargetDispatchName As %String, pRequest As Request, pResponseRequired As %Boolean = 1, pCompletionKey As %String = "", pDescription As %String = "") As %Status

All possible job states (from EnsConstrains.inc):

• $$$eJobStatusStarting
• $$$eJobStatusRegistered
• $$$eJobStatusVisiting
• $$$eJobStatusRunning
• $$$eJobStatusDeQueuing
• $$$eJobStatusQuiescent
• $$$eJobStatusError
• $$$eJobStatusHalted
• $$$eJobStatusTerminated

JGW (and therefore JBH) could be run as a separate container with TCP/IP interaction.