Блог

У меня есть агент по расписанию LotusScript, который обновляет представление после добавления множества новых записей в процессе синхронизации данных. Обновление работает просто отлично, за исключением любых вычисляемых полей, в которых используется @DBLookup. Я также пробовал использовать ComputeWithForm перед сохранением каждого нового документа. Из того, что я понял, ComputeWithForm не очень хорошо работает с @DBLookup, что является моим единственным реальным камнем преткновения. Если для этого есть стандартный обходной путь, пожалуйста, укажите мне правильное направление. Я дважды проверил, что сервер поиска совпадает с сервером агента и что сервер имеет доступ на уровне менеджера и все разрешения на документы и представления. Спасибо за всю вашу помощь.

запрошенный код:

Запланированный агент LotusScript

 Sub Initialize
    Dim s As New NotesSession
    Dim db As NotesDatabase
    Set db = s.CurrentDatabase

Set view = db.GetView("viewName")

Do
    Dim doc As New NotesDocument(db)

    --- other code that adds a new document---

    Call doc.ComputeWithForm(False, False)
    Call doc.Save(True, False)
Loop

Call view.Refresh()
 

Код формулы вычисленного поля в документе

 @DbLookup("Notes" : "NoCache"; "serverName" : "dbName.nsf"; "(columnName)"; fieldName; 2);
 

Как указано выше, @DBLookup работает нормально при запуске со стороны пользовательского интерфейса, агент по расписанию работает нормально, а форма computewith работает нормально и обновляет все вычисленные поля в форме, за исключением полей с @DBLookup. Мое предположение о том, что «ComputeWithForm плохо работает с @DBLookup», основано на нескольких других сообщениях на эту тему в Stack Overflow и других источниках, предоставленных мне нашим другом Google search.

Обратитесь к документу IBM «ComputeWithForm Не вычисляет значения по умолчанию, содержащие команды @Db» (#146472) для получения дополнительной информации.

Просто чтобы убедиться, что он пытался обновить вычисляемое поле, я изменил код формулы вычисляемого поля на следующий, и я получаю результат «без имени» при обновлении от запланированного агента и фактическое имя при обновлении из пользовательского интерфейса.

Код формулы вычисленного поля в документе

 empname := @DbLookup("Notes" : "NoCache"; "serverName" : "dbName.nsf"; "(columnName)"; fieldName; 2);
@If(@IsError(empname); "no name"; empname)
 

Скорее всего, это проблема безопасности. При запуске из пользовательского интерфейса пользователь получает доступ к базе данных, просмотру и документам, на которые ссылается функция @DbLookup. Когда вы запускаете его как агент на сервере, он работает под идентификатором сервера, а не идентификатором пользователя, и у него нет доступа. Даже если имя сервера находится в ACL обеих баз данных, у него нет доступа.

Старое (как и более 20 лет назад) решение этой проблемы состояло в том, чтобы поместить идентификатор реплики базы данных, содержащей вычисленные поля, в список управления доступом базы данных, которая является целью поиска. Прошло много времени с тех пор, как мне приходилось это делать. Я не помню, нужно ли было указывать идентификатор реплики в формате, где две 16-символьные части разделены двоеточием, или в виде одной 32-символьной строки. Использование идентификатора реплики было необходимо, поскольку это было до того, как агенты были подписаны. Личность пользователя, написавшего агент, установить не удалось, и использование идентификатора сервера при запуске агента обеспечило бы бэкдор для любого, у кого есть доступ к одной базе данных, для чтения любой другой базы данных на любом сервере в домене.

Новое решение состоит в том, чтобы убедиться, что подписавший агент имеет доступ к целевой базе данных, введя имя подписавшего (или группу) в список управления доступом целевой базы данных, а также заполнить поле Доверенные серверы в документе Сервера. Имя сервера, на котором находится база данных с агентом и вычисляемыми полями, должно находиться в поле Доверенные серверы в документе сервера сервера, на котором находится база данных, к которой пытается получить доступ @DbLookup. Это говорит этому серверу: «Можно доверять подписи агента в качестве действительного доказательства доступа, если она представлена в сеансе, открытом этим другим сервером».