Как использовать сеанс Intersystem в веб-сервисах

Я пытаюсь установить некоторую информацию о сеансе в одном веб-методе и вернуть ее в другом веб-методе, но данные сеанса всегда пусты во втором веб-методе. Вот что я пробовал

Веб-метод 1 — установка информации о сеансе

Method StartSession() As %String [WebMethod]
{
     set %session.NewSession = 1
     set %session.Data("key") = "dude"
     Quit "Session Started"
}

Веб-метод 2 — информация о сеансе Gets должна возвращать чувак, но возвращает пустое значение

Method TestSession() As %String [WebMethod]
{
    Quit $Get(%session.Data("key"))         
}

web-services intersystems-cache objectscript
person O.O    schedule 08.10.2012    source источник

Ответы (2)


arrow_upward
1
arrow_downward

Чтобы использовать сеансы с веб-службами Cache, вам необходимо установить параметр класса SOAPSESSION вашего класса веб-службы равным 1.

Это приведет к тому, что веб-служба вернет заголовок сеанса SOAP в ответе. Если вы используете клиент, рассчитанный на использование этого заголовка, возможно, вам не потребуется ничего настраивать. В противном случае вашему клиентскому приложению придется читать этот заголовок и включать его во все дальнейшие запросы, чтобы сервер мог знать, какой сеанс вы используете. Пример этого заголовка, приведенный в документации:

<csp:CSPCHD xmlns:csp="http://www.intersystems.com/SOAPheaders">value of
CPSCHD token</csp:CSPCHD>

Обратите внимание, что безопасность — это отдельная проблема, которая не рассматривается в вашем примере.

Также обратите внимание, что Intersystems решила, что веб-службы будут продолжать использовать лицензию в течение некоторого периода времени после того, как вызов был сделан. Я не могу найти документацию по этому поводу, и я считаю, что это что-то вроде нескольких секунд на вызов. Я считаю, что это может вызвать проблемы с лицензией, которых не возникло бы, если бы вы использовали другое программное обеспечение для предоставления веб-служб, и если бы это другое программное обеспечение вызывало кэш через какой-либо механизм, отличный от веб-служб. Я считаю, что это верно, даже если это другое программное обеспечение тщательно следует всем правилам лицензионного соглашения об именованных и анонимных пользователях. Однако я не уверен ни в одном из этих лицензионных материалов. Тем не менее, вы можете захотеть провести некоторое тестирование, прежде чем переходить к архитектуре.

person psr    schedule 08.10.2012
comment
О да. Я читал о части заголовка, но ничего не читал о параметре SOAPSESSION. Это помогло. - person O.O; 09.10.2012
comment
Это лучший способ сохранить значения переменных между вызовами веб-методов? - person O.O; 09.10.2012
comment
Является ли это наилучшим способом, как правило, сложный вопрос... Я обычно использую базовый механизм идентификатора сеанса, который передается как заголовок HTTP и используется в качестве ключа к данным сеанса. Для промышленного применения я обычно оборачиваю код Intersystem кодом, который могу изменить. Итак, у меня может быть подкласс %SOAP.WebService, который заменяет %session моим собственным классом, возможно, с явными свойствами вместо %session.Data. Действительно, я бы, наверное, использовал чью-то реализацию веб-сервисов и вызывал Cache оттуда, если бы мне приходилось использовать веб-сервисы. - person psr; 09.10.2012
comment
относительно обновления лицензии: ссылка - person kazamatzuri; 09.10.2012

arrow_upward
0
arrow_downward

В качестве альтернативы ответу psr другим способом обработки состояния является использование настраиваемых заголовков SOAP.

Например:

Создайте класс для своих пользовательских заголовков SOAP, как показано ниже:

Class Headers.TimeStamp Extends %SOAP.Header
{
     Property TimeSent As %TimeStamp;    
}

В веб-методе сделайте следующее:

set h=##class(Headers.TimeStamp).%New()
set h.TimeSent=$ZTIMESTAMP
do ..HeadersOut.SetAt(h,"Timestamp")

Это создаст следующий заголовок SOAP:

  <SOAP-ENV:Header>
    <TimeStamp xmlns:hdr="http://www.myapp.org">
      <TimeSent>60712,70996.027Z</TimeSent>
    </TimeStamp>  
  </SOAP-ENV:Header>

Это позволит поддерживать состояние в заголовках SOAP, а не использовать управление сеансом Cache.

person O.O    schedule 10.10.2012