FWD » Core Development » Base Language

The purpose of this is to allow converted 4GL code to uniquely identify a given session. A customer has requested this to allow them to implement some internal licensing logic.

How will customers know when older sessions have been ended when implementing licensing rules?

I expect that the customer will likely implement their own "licenses in use" table (see #4522) in which one field will be the session id. They can implement Session Init Term Hooks in Java to remove the record when the session exits.

For the purposes of this task, we just need to have that unique ID for the lifetime of the session.

The hook seem to be in Java, while the customers want to implement it in 4GL. I think they will come back to us to ask for it when this task is completed.

Maybe, but it isn't hard to implement the cleanup of a record using Java code. The initial insertion can be done in the 4GL initialization code for the application.

Can we have multiple "connection" sessions (DirectSession / VirtualSession) for one client (not necessarily simultaneous)?

Actually obviously that's how appserver works. I'm just trying to figure out if there is any case where the id should be stable in different BaseSession objects.

You can have a virtual session while in an active direct session. You cannot have a virtual session on its own, the idea is that it is a special server-to-server multiplexed session.

You don't have to map the session id to the FWD direct session or FWD virtual session per se. We don't need to distinguish between these FWD session types. From a 4GL code perspective, there is only ever one "session" and that is what we are representing here.

I'm just trying to figure out if there is any case where the id should be stable in different BaseSession objects.

I don't want to map this to a FWD session. This is about the 4GL session, which follows the Highlander principle..

• the unique conversation (with standalone gui/chui/batch processes and web gui/chui/embedded);
• the unique connection to appserver (running external procedures)?
• the unique connection to rest / soap?

the unique conversation (with standalone gui/chui/batch processes);

Yes

the unique connection to appserver (running external procedures)?

Yes, though the lifetime is dependent upon the connection type (stateful, state free, state reset...).

the unique connection to rest / soap?

Yes, though the lifetime is dependent upon the agent.

I think we don't need to consider this too much. Calculate the value only when it is first read and store it in the SessionUtils.WorkArea. The lifetime of that context will already be properly managed and you don't need to deal with it. If the value is never read, then it is never calculated and is just set to null by default.

What is client-principal:session-id https://docs.progress.com/bundle/abl-reference/page/SESSION-ID-attribute.html#SESSION-ID-attribute . We have that implemented in com.goldencode.p2j.util.ClientPrincipal as SESSION_ID(AttrType.CHAR, 0xf, "SESSION-ID"),.

Galya B wrote:

What is client-principal:session-id https://docs.progress.com/bundle/abl-reference/page/SESSION-ID-attribute.html#SESSION-ID-attribute . We have that implemented in com.goldencode.p2j.util.ClientPrincipal as SESSION_ID(AttrType.CHAR, 0xf, "SESSION-ID"),.

The attribute is r/w, so it can be set by the application to anything (thus uniqueness is not guaranteed). And it belongs to CLIENT-PRINCIPAL.

The client-principal is a kind of 4GL based security-related token that identifies an authenticated identity. It is not guaranteed to be used at all (you have to write your 4GL code to use it) and this usage requires other code to handle the authentication. It is also not guaranteed to be stable for the entire lifetime of the 4GL session. It can be swapped out or logged out and replaced.

Our session-id will have no relation to the client-principal.

Ok, thanks for the explanations, it's just that the new keyword will be quite similar to the old one.

I expect we would use the same keyword. There is nothing wrong with that.

If we reuse this keyword, SESSION-ID will need to be extracted to its own interface, specific handle.unwrap added for this attribute, and some conversion rules changes, also.

I was going with a similar, but not exactly the same keyword, so I'll stick with it.

I was going with a similar, but not exactly the same keyword, so I'll stick with it.

I don't want to add a keyword where there other will do.

I want to know what I'm doing, but I don't.

In this case, since we already have a keyword and we even have an attribute with that name, there are no changes needed in progress.g. The other changes are still needed (e.g. methods_attributes.rules etc...).

Code Review Task Branch 4855a Revision 14634

No objections.

We are trying to avoid conversion changes in trunk for a short time, so we may not merge this until later next week.

You can rebase and merge 4855a to trunk.

The changes in trunk rev 14661 are not OK. As SESSION-ID exists now at both CLIENT-PRINCIPAL and SESSION, we need this attr in a dedicated interface, with its own handle.unwrap method (as mentioned at #4855-19.

Do I need to invent something or you can point me to an example or programming principle?

SESSION:SESSION-ID will become writable.

Can I now have a different keyword like I wanted, or we'll make it writable although it makes no sense?

This test needs to work properly to validate the fix:

def var ch as char.
def var h as handle.
create client-principal h.

h:session-id = "abc".
ch = h:session-id.
message ch.

session:session-id = "123" no-error. // this will raise an ERROR condition
message error-status:error error-status:get-message(1).
ch = session:session-id.
message ch.

• extract the SESSION-ID getter/setter into their own interface (both setters with character and String parameters)
• add this interface to CommonSession and ClientPrincipal
• add a handle.unwrapSessionId API for this interface
• implement the setter in SessionUtils, to just call readOnlyError
• change methods_attributes.rules to use this 'unwrap' API.

4855b r14663-14664 I can't make it work:

Sessionid.java:36: error: cannot find symbol
    [javac]          silent(() -> new character("123").setSessionId());
    [javac]                                           ^
    [javac]   symbol:   method setSessionId()
    [javac]   location: class character
    [javac] /home/gbb/Code/testcases-working/src/com/goldencode/testcases/galya/Sessionid.java:42: error: no suitable method found for assign(no arguments)
    [javac]          ch.assign();
    [javac]            ^
    [javac]     method BaseDataType.assign(BaseDataType) is not applicable
    [javac]       (actual and formal argument lists differ in length)
    [javac]     method BaseDataType.assign(jobject<?>) is not applicable

I think all is correct, but I wasn't able to find the right unwrap in methods_attributes.rules. I tried different variants, all seem the same to me.

You need this code adjusted for SESSION-ID, in methods-attributes.rules, the section for SESSION handle:

                  <rule>ftype == prog.kw_sessn_id
                     <action>hwrap = "SessionId"</action>
                     <action>methodText = "SessionUtils.getSessionId"<action>
                     <rule>isAssign
                        <action>methodText = "SessionUtils.setSessionId"</action>
                     </rule>
                  </rule>

4855b r14665 ready for review.

This is the output of the test proc:

abc
yes **SESSION-ID is not a settable attribute for PSEUDO-WIDGET. (4052)
c76891eb-50c0-4b60-8c6b-1c4e70baef3b

Review for 4855b/14665 - I'm OK with the changes.

Do I merge?

You can merge to trunk.

Task branch 4855b was merged to trunk as rev 14665 and archived.