For higher performance it's better to keep the data in InterSystems platform and sync it with remote db periodically.

To download the data via xDBC you have two main approaches:

  • Interoperability (Ensemble) SQL inbound adapter
  • "Raw" access via %SQLGatewayConnection or %Net.Remote.Java.JDBCGateway

Interoperability approach is better as it solves most problems and user should just enter the query, etc. "Raw" can be faster and allows for fine-tuning.

Now, to keep data synced there are several approaches available:

  • If source table has UpdatedOn field, track it and get rows updated only after last sync.
  • Journals: some databases provide parsable journals, use them to determine which rows changed in relevant tables.
  • Triggers: sometimes source table has triggers (i.e. Audit) which while do not provide explicit UpdatedOn field nonetheless can be used to determine row update time.
  • Hashing: hash incoming data and save the hash, update the row only if hash changed.

If you can modify source database - add UpdatedOn field, it's the best6 solution.

Linked tables allow you not to store data permanently, but the cube would be rebuilt each time. With other approaches syncing cube is enough.

Also check this guide on DeepSee Data Connectors.

I have no real answer to the logon issue

What about custom login pages?

<html>
    <head>
        <title>cUSTOM LOGIN PAGE</title>
    </head>
    <body>
        <div style="">
            <form name="loginForm" class="form-signin" method="post" action="#("./index.csp")#">
                <p id="caption">Registration system</p>
                <input name="CacheLogin" value="1" type="hidden">
                <input id="CacheUserName" type="text" class="input-block-level" name="CacheUserName" placeholder="Login" value="_SYSTEM">
                <input type="password" class="input-block-level" name="CachePassword" placeholder="Password" value="SYS">
                <button class="btn btn-small btn-primary" type="submit" style="font-size: 1em;">Login</button>
            </form>
        </div>
    </body>
</html>

1. Export Api package.

2. Uncompile and Delete all classes from Api package regardless of the case.

3. Delete package with

write $System.OBJ.DeletePackage("package name") 

4. Check if there's anything related to jitPod.Api package left in:

zw ^oddPKG

Delete ONLY entries related to your package.

5. In exported code replace Api with api for all classes. 

6. Restart Cache.

7. Import classes.

I'm calling load code like this:

csession ensemble "##class(isc.git.GitLab).load()"

ObjectScript:

/// Do a full load
/// do ##class(isc.git.GitLab).load()
ClassMethod load()
{
    try {
        set dir = "/src"
        do ..log("Importing dir " _ dir)
        do $system.OBJ.ImportDir(dir, "*.xml", "c", .errors, 1)
        throw:$get(errors,0)'=0 ##class(%Exception.General).%New("Load & compile error")
        halt
    } catch ex {
        write !,$System.Status.GetErrorText(ex.AsStatus()),!
        do $system.Process.Terminate(, 1)
    }
}

This way process terminates abnormally on error:

do $system.Process.Terminate(, 1)

And it's usually reported as error in CI/CD systems.

Additionally you can grep for "Load & compile error".

I'm currently writing a series of articles on continuous delivery, check it out (latest part).