BusinessObjects (BoE) / Crystal Server: стари/мъртви сесии не се изчистват

Имаме сървър BusinessObjects Enterprise XI, който според мен е подобен (ако не и същия) на Crystal Reports Server 2008.

Имаме малък брой едновременни лицензи и това никога не е било проблем (което забелязахме), но напоследък изглежда, че сървърът не се отървава от мъртвите сесии и все още ги брои като активни (което се брои срещу нашето лицензиране).

Не използвахме сървъра Tomcat за присъствие в мрежата, така че това също може да го засяга (използваме уеб сървъра, който се доставя вътрешно със сървъра -- не съм сигурен какво представлява. Можете ли да кажете, че наследих този проект?)

Единственото решение, което успях да използвам досега, е рестартирането на сървърите на BoE (те са няколко отделни приложения, но не мога да намеря кое управлява сесиите и затова всички трябва да бъдат рестартирани. Грубо.

Някаква идея откъде мога да започна да ровя в това? Претърсих всякаква документация, но все още не съм намерил решението.

Благодаря предварително за всяка помощ, която можете да окажете!


person SeanKilleen    schedule 02.02.2012    source източник


Отговори (2)


Лицензът се освобождава, когато EnterpriseSession бъде прекратена. EnterpriseSession обаче не се прекратява, когато браузърът е затворен; потребителят трябва изрично да „излезе“ (в ePortfolio/InfoView), за да прекрати сесията.

Можете също така да съкратите продължителността на сесията по подразбиране.

От Ръководството на администратора на BusinessObjects Enterprise XI 3.1 (страници 444-445):

Корпоративните системи, предназначени да обслужват голям брой потребители, обикновено изискват някаква форма на разпределена сигурност. Корпоративна система може да изисква разпределена сигурност, за да поддържа функции като прехвърляне на доверие (способността да се позволи на друг компонент да действа от името на потребителя) BusinessObjects Enterprise адресира разпределената сигурност чрез внедряване на механизъм за билети (такъв, който е подобен на механизма за билети Kerberos ). CMS предоставя билети, които разрешават на компонентите да извършват действия от името на определен потребител. В BusinessObjects Enterprise билетът се нарича токен за влизане.

Този маркер за влизане се използва най-често в мрежата. Когато даден потребител се удостовери за първи път от BusinessObjects Enterprise, той или тя получава токен за влизане от CMS. Уеб браузърът на потребителя кешира този маркер за влизане. Когато потребителят направи нова заявка, други компоненти на BusinessObjects Enterprise могат да прочетат токена за влизане от уеб браузъра на потребителя.

Като цяло сесията е връзка клиент-сървър, която позволява обмен на информация между двата компютъра. Състоянието на сесията е набор от данни, които описват атрибутите на сесията, нейната конфигурация или нейното съдържание. Когато установите връзка клиент-сървър през мрежата, природата на HTTP ограничава продължителността на всяка сесия до една страница с информация; по този начин вашият уеб браузър запазва състоянието на всяка сесия в паметта само докато се показва всяка отделна уеб страница. Веднага щом преминете от една уеб страница към друга, състоянието на първата сесия се отхвърля и се заменя със състоянието на следващата сесия. Следователно уеб сайтовете и уеб приложенията трябва по някакъв начин да съхраняват състоянието на една сесия, ако трябва да използват повторно информацията й в друга.

BusinessObjects Enterprise използва два общи метода за съхраняване на състоянието на сесията:

• Бисквитки—Бисквитката е малък текстов файл, който съхранява състоянието на сесията от страна на клиента: уеб браузърът на потребителя кешира бисквитката за по-късна употреба. Токенът за влизане на BusinessObjects Enterprise е пример за този метод.

• Сесийни променливи – Сесийната променлива е част от паметта, която съхранява състоянието на сесията от страната на сървъра. Когато BusinessObjects Enterprise предостави на потребител активна самоличност в системата, информация като типа удостоверяване на потребителя се съхранява в променлива на сесията. Докато сесията се поддържа, системата нито трябва да подканва потребителя за информацията втори път, нито трябва да повтаря каквато и да е задача, която е необходима за изпълнение на следващата заявка. За внедрявания на Java сесията се използва за обработка на .jsp заявки; за .NET внедрявания, сесията се използва за обработка на .aspx заявки.

Забележка:

В идеалния случай системата трябва да запази променливата на сесията, докато потребителят е активен в системата. И за да се гарантира сигурността и да се сведе до минимум използването на ресурси, системата трябва да унищожи променливата на сесията веднага щом потребителят приключи работата със системата. Въпреки това, тъй като взаимодействието между уеб браузър и уеб сървър може да бъде без състояние, може да бъде трудно да се разбере кога потребителите напускат системата, ако не излязат изрично. За да се справи с този проблем, BusinessObjects Enterprise прилага проследяване на сесии.

CMS прилага прост алгоритъм за проследяване. Когато потребител влезе, му се предоставя CMS сесия, която CMS запазва, докато потребителят излезе или докато не бъде освободена променливата на сесията на сървъра на уеб приложения.

Сесията на сървъра на уеб приложения е проектирана да уведомява CMS на повтаряща се основа, че все още е активна, така че сесията на CMS се запазва, докато съществува сесията на сървъра на уеб приложения. Ако сесията на сървъра на уеб приложения не успее да комуникира със CMS за период от десет минути, CMS унищожава CMS сесията. Това обработва сценарии, при които компоненти от страна на клиента се изключват нередовно.

person craig    schedule 03.02.2012
comment
Въпрос относно: CMS прилага прост алгоритъм за проследяване. Когато потребител влезе, му се предоставя CMS сесия, която CMS запазва, докато потребителят излезе или докато не бъде освободена променливата на сесията на сървъра на уеб приложения. Когато казват, че сесията на сървъра за уеб приложения е освободена, те имат предвид Tomcat, предполагам, но ние не използваме Tomcat. Кой е най-добрият начин за актуализиране на това изчакване на сесията за инсталации, различни от Tomcat? Благодаря за страхотния откъс от ръководството на администратора! - person SeanKilleen; 07.02.2012
comment
Друг последващ въпрос: виждам, че ако сесията на сървъра на уеб приложения не успее да комуникира със CMS за период от десет минути, CMS унищожава сесията на CMS. ние използваме вътрешния уеб сървър и забелязах сесии, останали за дни в Crystal (където потребителите вече нямат отворени прозорци на браузъра и последното влизане е преди дни). Къде се прилага това 10-минутно правило, ако не се използва инсталацията на Tomcat? - person SeanKilleen; 07.02.2012
comment
1) Или Tomcat, или IIS (зависи коя версия сте инсталирали). 2) Откъде знаете, че отворените сесии са свързани с тези конкретни браузъри? Определихте ли какви са настройките ви по подразбиране, Enterprise timeout? Ако създадете сесия с браузър, след което го оставите да остане (не го затваряйте) за период на неактивност, който трябва да причини повторно удостоверяване, какво се случва? Използвате ли SSO? - person craig; 07.02.2012

Имахме подобен проблем, при който администраторът винаги се отчиташе два пъти от нашия малък брой наименувани лицензи, нашият доставчик се оплака на SAP от наше име и те ни дадоха безплатни наименувани лицензи, тъй като не можаха да разрешат проблема. Може би вашият доставчик може да включи SAP за отдалечено и да ви прегледа.

Едновременните лицензи, когато потребителите не успеят да излязат, се изчистват чрез рестартиране на централния конфигурационен мениджър, така ми показа SAP и да, това е пълно рестартиране.

Ако имате отворени отчети на живо в процес на разработка чрез кристални отчети, ще загубите връзка с вашата база данни, така че може да искате да ги затворите или запазите, преди да рестартирате.

Сървърите в крайна сметка ще се върнат и вашите отворени сесии ще бъдат изчистени напълно

person user4000990    schedule 02.09.2014