Ensemble settings can be specified for a namespace. So you specify common setting values (or defaults) in production class, and in a SMP you define the instance-specific settings.

The problem I see here is, if only one of the data object's properties has changed, how do we know which? Or do we simply overwrite all properties? 

If you use old json classes, you can send only changed properties, for example this json payload would be converted into  Sample.Person object with id=1 and all properties taken from disk except for Name property, which would be set to Bob:

{ _class: "Sample.Person", _id: 1, Name: "Bob" }

With new json you can get dynamic object from json with only modified properties and change persistent object by iterating over defined properties of a modified object.

I usually write Abstract REST class for handling all REST technical checks and conversions, and inherit all the other REST brokers from it, so they only contain logic related to calling business logic and outputting the results.

Request -> Abstract REST -> REST -> Business Logic -> Data

For example check this abstract broker for json->obj conversion example.

Here are some articles on community about that:

• Free Text Search by Kyle Baxter
• iKnow demo apps (1, 2, 3, 4) by Benjamin DeBoe 

• Session Cookie Path - Scope of the session cookie. This determines which URLs the browser uses to send the session cookie back to Caché. If your application name is myapp, it defaults to /myapp/ meaning it only sends the cookie for pages under /myapp/. If you restrict this to only what is required by your application, it prevents this session cookie being used by other CSP applications on this machine, or from being seen by any other application on this web server. On the other hand, browsers and cookies are case sensitive. Setting the session cookie to '/' can prevent license or session problems if, for example, an application name changes from capital to lowercase letters.
• Login Cookies hold information about the most recently logged-in user. If you want to keep your users from having to log in too often, but you want your applications to remain distinct and unconnected, use Login Cookies.

As every BP is also a SQL table, you can select active processes which are older than 1 day  with this query:

SELECT ID, %SessionId, %SuperSession, %TimeCreated, DATEDIFF('day',%TimeCreated, CURRENT_TIMESTAMP) AS DaysOld
FROM <business_process_table>
WHERE DATEDIFF('day', %TimeCreated, CURRENT_TIMESTAMP) > 1
      AND %TimeCompleted IS NULL

As BO messages also get logged, you can check Ens.MessageHeader table for message processing time.

How did you get this query?

You need to remove ApplicationID from the query, as that field does not exist. Maybe it was an ID field instead and got changed into ApplicationID somehow?

If that base class has a property that is another class, do I have to add the DSTIME parameters to that secondary class? 

No. DSTIME needs to be defined only for a base class of a cube (fact table class). 

It works like this:

1. During the compilation if DSTIME parameter is present %Save/%Delete methods would write the fact class, id and action into ^OBJ.DSTIME global
2. Cube synchronization job would iterate over this global but only over fact class and process them accordingly
3. %PurgeDSTIME from %DeepSee.Utils class would clear all processed records in ^OBJ.DSTIME global and all records that are not from fact classes

You can only read into simple local variables, so it should be like:

set Name=##class(Example.Team1).%New()
read "enter your name :", NameStr
set Name.EmpName = NameStr

There are also utility prompt methods, see %Library.Prompt class. For example GetString method supports object properties:

set Name=##class(Example.Team1).%New()
do ##class(%Library.Prompt).GetString("enter your name", Name.EmpName)

Yes, $ZStrip. For example:

Write $ZStrip("  ,a b, ","<>W")
>,a b,
Write $ZStrip("  ,a b, ","<>WP")
>a b

You should use any (choose the one most relevant to your requirements) of the new stream objects. See subclasses of %Stream.Object.

Looks nice, but does not resolve short class references to the library package (%String for example) and current package.

Here's my settings:

The application also has a %DB_CACHESYS role on a second tab.

Installer xml and a bat file to load it into Cache and execute.

Can you please elaborate upon what do you want to achieve?

Both of these tools are for GitHub and Cache (not Git and Cache, but with easy customization required to support some other Git server API over HTTP).

Cache Updater is a simple Cache task. You specify GitHub information (repository and user/pass if it's a private repo) and namespace. Then you set a schedule and that's it. Every time the tasks runs it downloads (and compiles) code from GitHub and into Cache Namespace.

CacheGitHubCI is a full fledged CI system. You may specify pre and post compile actions, unit tests, etc. The results and timings of each build and action are saved and there are DeepSee dashboards available. GitHub webhooks are supported, which allows running builds immediately after there is a new commit in a repository.

Which one you choose depends on your requirements. Cache Updater is very easy to set up, CacheGitHubCI offers more features.

Both of them are built atop GitHub COS API, which provides COS wrappers for GitHub API.

Please post the property definition.

by default she send the value as DISPLAYLIST

How do you get property value?

Here's the version for windows and most linux distros:

ClassMethod RunPage(Url As %String = "http://intersystems.com")
{
    #Include %occOptions
    Set Browser = $Select($$$isWINDOWS:"start", $$$isUNIX:"x-www-browser", 1:"x-www-browser")
    Set Command = Browser _ " " _ Url
    Do $ZF(-1, Command)
}