New post
AllAccepted answers
Eduard Lebedyuk · Sep 19, 2016

IF we use cookies, they will be stored in the Session Cookie Path.

Cookie has a property named path. Whed browser determines, does the cookie apply to a current page, it checks if the cookie path is less or equal to current URL.

I'm thinking that this login cookie would be used somehow if the Login Cookie is selected? Or not used? 

It would be used, if checked.

what does happen if the Login Cookie is selected in the web application?

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. For Login Cookies, place each application in a separate session. Then authentication is shared only when an application is entered for the first time. Login Cookies applications do not form a group. So after login, changes in authentication in one application do not affect the other applications. Documentation.

What could we store in a cookie? Can we possibly find out if a second tab has been opened by using a cookie?

You can store text values in cookie. I suggest you read wiki article on them.

Eduard Lebedyuk · Sep 16, 2016
  • 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.
Eduard Lebedyuk · Sep 16, 2016

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.

Eduard Lebedyuk · Sep 14, 2016

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
Eduard Lebedyuk · Sep 14, 2016

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)
Eduard Lebedyuk · Sep 12, 2016

Here are some thoughts:

  • Write Source Control Hook that implemets OnAfterSave method and checks there (or maybe some other entry point). There are several sample source control hook classes, check them out.
  • Use ^rINDEXCLASS global (key - class name in uppercase) - it contains some basic information such as modification time (1st position) and hash (13th position). You can monitor it and if time or hash changes then record the new class version.
  • Use lock table to see what classes are currently being edited
  • Use $$$defClassKeyGet macros (see %Dictionary.ClassDefinition/%Dictionary.CompiledClass definitions, they use these macros a lot) to get info about modification time/hash and the changes themselves
  • %Compiler.UDL.TextServices to get the class text

I would have done it like this:

  • Background process monitors ^rINDEXCLASS global
  • Upon finding changes get the current class code via %Compiler.UDL.TextServices class,  GetTextAsStream method
  • Write this information into your own class (classname, timestamp, user, classtext, diff, previousversion)

Modification of system classes is not a very good idea:

  • They are lost on update
  • User may not have access required to install these changes

That being said, the best solution in my opinion is to setup your critical/production systems in such a way, that developers do not have direct write access to them. Each of the developers have their own environment where they can do whatever and then commit it to source control system. Continuous integration solution (or one developer or a script) then uploads the code (after it passes the tests) to the production server. There are several source control/continuous integration systems available for Caché.

It is a good idea that a change can only be done via source control commit. All other changes simply should not exist.

Eduard Lebedyuk · Sep 6, 2016

There is a beforeunload HTTP event which is fired when the window, the document and its resources are about to be unloaded. Handle this event in your js code and from there you can send an HTTP request to a server (I usually use GET /webapp/logout), which would do something like this:

ClassMethod logout() As %Status
{
    #dim %session As %CSP.Session
    set st = %session.Logout(1)
    set %session.EndSession = 1
    return st
}
Eduard Lebedyuk · Aug 31, 2016

 I'd also love to see the web application's properties programmatically, if possible (such as the physical files path).

Use Security.Application class directly, or preferably via %Installer manifest.

but I honestly don't know why it's choosing that web application over the default of /csp/default-namespace

Uncompile and compile ZEN classes after setting default web application. Or you can try to set HOMEPAGE parameter in the application class.

My question is, if we go to using Group By ID (which is currently null) in the web application, will this fix the sharing of %session Data? (This is why I have to make sure I'm editing the correct web application!)

If the user opens one web application in two tabs, they would be sharing a session (and namespace). Group By ID would only help if you have N different applications and would specify N different values for Group By ID property. In that case, they should use N different sessions.

Finally, we have a web application for each namespace; will we need the Group By ID for each application defined for each namespace, and should it be the same ID?

Depends, if you want to share %session or not.