Проверка количества лицензий

[Dolores]

В связи с ограниченным количеством пользовательских лицензий (Axapta 2009) поступила задача при запуске сеанса определенным пользователем (допустим программист или директор) автоматически завершать одну из активных сессий, чтобы данный пользователь мог всегда иметь доступ в программу.
Можно ли это реализовать?
Класс Application доработать не получится, т.к. если лицензий не хватает, мы в него даже не попадаем...

[S.Kuskov]

Цитата:

Сообщение от Dolores

Класс Application доработать не получится, т.к. если лицензий не хватает, мы в него даже не попадаем...

Я думаю, что выкинуть пользователя из аксапты внешними средствами не получится.
Я бы мыслил в сторону следующей схемы:
Придерживать как минимум одно свободное место для vip-пользователей, искусственно выкидывая входящих пользователей (модификация класса Application). Если место занимает vip-пользователь, то выкидывать кого-то из тех кто уже работает, все равно освобождая одно место для вновь входящих.

[gl00mie]

Цитата:

Сообщение от Dolores

В связи с ограниченным количеством пользовательских лицензий (Axapta 2009) поступила задача при запуске сеанса определенным пользователем (допустим программист или директор) автоматически завершать одну из активных сессий, чтобы данный пользователь мог всегда иметь доступ в программу.

Программист в той же рабочей системе обычно не является приоритетным пользователем - у него есть разработка и тест. Если доступ нужен администратору Аксапты - тогда еще может быть, и то вопрос, зачем. Очень многие вещи можно решать извне системы, включая мониторинг активности и проч., а для работ наподобие переноса модификаций или настройки прав доступа можно выделить регламентированное временное окно, которое должно приходиться на периоды минимальной активности пользователей.
Что же касается доступа директора - это вообще интересная тема По аналогии с каким-нить производственным процессом: надо директору пройти по цеху - а там толпа рабочих суетится, ну так ведь можно охрану позвать, пускай вытолкают кого-нить взашей. Ничего что рабочий в это время на станке детальку вытачивал, или в форму расплавленный металл заливал, или краник цистерны с реагентами закручивал, и в итоге работа пропала...

PS. Для 2009-й есть дешевые лицензии на тот же Business Connector, часть задач по мониторингу и каким-то регламентным операциям можно выполнять через него, поскольку обычные пользователи используют другой тип лицензий. Также можно настроить автоматическое завершение пользовательских сессий по таймауту и программно ограничить возможность запускать несколько клиентов под одним пользователем. А грубо выкидывать работающих пользователей из системы - это вот как с проходом по цеху в примере выше...

[pitersky]

Я думаю, что при именно такой реализации вы утонете в море негатива. Как определить, какая именно сессия должна быть завершена? На основании каких критериев?
Я бы лучше копал в сторону мониторинга активности пользователей. Когда лицензий не хватает - очень многие запускают аксапту "на всякий случай", ничего в ней не делая.

[Omeo]

Цитата:

Сообщение от Dolores

Можно ли это реализовать?

я это делал не с помощью классов и тд, а просто заходил с помощью MSSQL Management Studio и удалял понравившуюся (или непонравившуюся) запись в SYSCLIENTSESSIONS

думаю, можно организовать что то в этом направлении

[A_BAS]

А чтобы уменьшить вероятность превышения количества лицензий можно использовать вот это
Автоматическое завершени сессии

Чтобы пользователи "ушедшие покурить", отваливались автоматом

[Player1]

Цитата:

Сообщение от A_BAS

А чтобы уменьшить вероятность превышения количества лицензий можно использовать вот это
Автоматическое завершени сессии

Чтобы пользователи "ушедшие покурить", отваливались автоматом

Можно вопрос? - Если у пользователя без его участия строится долгий отчет, запущена долгоиграющая обработка допустим на ночь, сессия завершится по истечении таймера?

[S.Kuskov]

Цитата:

Сообщение от Player1

Можно вопрос? - Если у пользователя без его участия строится долгий отчет, запущена долгоиграющая обработка допустим на ночь, сессия завершится по истечении таймера?

Долгие отчеты, и долгоиграющие обработки должны выполняться в пакетном режиме на сервере а не локально у пользователя.

[A_BAS]

Цитата:

Можно вопрос? - Если у пользователя без его участия строится долгий отчет, запущена долгоиграющая обработка допустим на ночь, сессия завершится по истечении таймера?

Эксперименты показывают что отчет строится, но сразу после вывода на экран сессия срубается.
На практике я бы не стал устанавливать таймаут для пользователей, которые запускают что-либо на ночь.

[gl00mie]

Цитата:

Сообщение от Player1

Если у пользователя без его участия строится долгий отчет, запущена долгоиграющая обработка допустим на ночь, сессия завершится по истечении таймера?

Выход по таймауту обрабатывается только в периоды простоя и никакие обработки не прерывает. Однако, хочу предостеречь на тему выставления слишком большого (больше 15-и минут) таймаута: при такой настройке весь этот функционал может не заработать, см. вот эти рассуждения.

[iCloud]

Цитата:

Сообщение от Dolores

В связи с ограниченным количеством пользовательских лицензий (Axapta 2009) поступила задача при запуске сеанса определенным пользователем (допустим программист или директор) автоматически завершать одну из активных сессий, чтобы данный пользователь мог всегда иметь доступ в программу.
Можно ли это реализовать?
Класс Application доработать не получится, т.к. если лицензий не хватает, мы в него даже не попадаем...

Сделайте, чтобы последнюю лицензию мог забрать только определенный человек - директор
А если он её уже забрал, то не ограничивать.

[Dolores]

А как лучше проводить мониторинг активности пользователей, чтобы определить делает ли пользователь что-то в программе или просто сеанс открыл ? По какой таблице? К журналу базы данных нельзя привязаться, т.к. не все действия пользователей журнализируются...

[iCloud]

Цитата:

Сообщение от Dolores

А как лучше проводить мониторинг активности пользователей, чтобы определить делает ли пользователь что-то в программе или просто сеанс открыл ? По какой таблице? К журналу базы данных нельзя привязаться, т.к. не все действия пользователей журнализируются...

На случай если пользователь ничего не делает - есть timeout сессии, тут придумывать не нужно.

В AX 2012 следующие методы реализуют подсчет числа активных сессий:
Info::licensedUsers(),
Info::licensedComUsers(),
так же в Info::licensedUsersTotal() идет подсчет.
Есть замечательный класс SysUserOnline:

server static container getAllOnlineUserInfo()
{
    int num;
    int idleTicks;
    container users;
    xSession session;
    UserInfo userInfo;
    AOSClientMode clientMode;
    SysClientSessions clientSessions;
    ;

    num = 0;

    // SessionId field is not recognized
    // BP deviation documented
    while select clientSessions where
    //clientSessions.Status == SessionState::Running || clientSessions.Status == SessionState::Killed
    clientSessions.Status == SessionStatus::Running
    || clientSessions.Status == SessionStatus::Killed
    || clientSessions.Status == SessionStatus::MarkedAsKill
    {
        session = new xSession(clientSessions.SessionId);
        if(clientSessions.UserId)
        {
            select firstonly userInfo
                where userInfo.Id == clientSessions.UserId;

            if (userInfo) //If no SYS_OPEN_DOMAIN access they should not be shown
            {
                num++;
                clientMode = AOSClientMode::Thin;
                idleTicks = 0;

                users += [[clientSessions.SessionId,
                           clientSessions.UserId,
                           clientSessions.ClientType,
                           DateTimeUtil::applyTimeZoneOffset(clientSessions.LoginDateTime, DateTimeUtil::getUserPreferredTimeZone()),
                           clientSessions.ClientComputer,
                           session.databaseSpid(),
                           userInfo.Name,
                           clientMode,
                           idleTicks
                           ]];
            }
        }
    }
    users = [users,num];
    return users;
}

Ограничить количество входов одного пользователя. В классе Info:

void startupPost()
{
    int         counter;
    int         num = 0;
    int         maxSessions = Info::licensedUsersTotal();
    xSession    session;
    UserInfo    userInfo;
    UserId      currentUserId;
    ;

    currentUserId = curuserid();
    for(counter = 1; counter < maxSessions;counter++ )
    {
        session = new xSession(counter, true);
        if(session && session.userId())
        {
            select firstOnly userInfo
                where userInfo.id == session.userId();

            if (userInfo && (currentUserId == session.userId()))
            {  
                num++ ;
            }
        }
    }

    if (num > 1)
    {
        if(ox::yesno("Вы пытаетесь посторно войти пот тем же именем пользователя, а это не разрешается. Все равно войти?",
                   DialogButton::Yes, "Войти", "Выйти") == DialogButton::No)
        {
            infolog.shutDown(true);
        }
    }
}

[sukhanchik]

Цитата:

Сообщение от Dolores

А как лучше проводить мониторинг активности пользователей, чтобы определить делает ли пользователь что-то в программе или просто сеанс открыл ? По какой таблице? К журналу базы данных нельзя привязаться, т.к. не все действия пользователей журнализируются...

Один из вариантов решения - в этой теме Функционал отправки клиентских сообщений и не только
Здесь можно снять скриншот экрана у любого пользователя.

Второй вариант решения - это написать тулзу а-ля регистратор задач (Task Recorder), которая будет логировать действия пользователя.
Соответственно - ее можно вставить в метод \Classes\ClassFactory.formRunClass(), в RunBase - и тогда все эти вызовы можно будет логировать.
Но этот вариант решения хорош только в том случае, когда Вам нужно промониторить конкретного пользователя или конкретный объект в АОТе (например, сколькими пользователями используется эта форма). Логировать все подряд по всем объектам - мне кажется будет излишней нагрузкой на систему.