Меню

Рекомендация. Оптимизация нумерации операций для предотвращения пропусков

|

Автор приводит простую и эффективную процедуру настройки для предотвращения пропусков в нумерации уведомлений о поддержке, запросов на изменение и идентификаторов в модуле Change Request Management (ChaRM).

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

  • Пользователь заполнил данные в ракурсе “Transaction Processing” (транзакция CRMD_ORDER), но решил, что сообщение в сервисную службу создавать не требуется.
  • Пользователь выполнил тестирование в ракурсе “Transaction Processing” и нажал кнопку “Create Support Notification” или “Create Change Request”.

Следовательно, общее количество бизнес-операций в модулях Issue Management, Service Desk и Change Request Management (ChaRM) при создании отчетности окажется некорректным. Независимо от намерений пользователя бизнес-операции присваивается следующий порядковый идентификационный номер, и в нумерации фактически созданных сообщений в сервисную службу возникает пропуск. В данной статье описываются действия, выполнение которых позволит предотвратить возникновение таких нежелательных пропусков и избежать ошибок в отчетах.

Пропуск возникает потому, что установлен флажок “Early No. Assgt” (т.е. флажок активации предварительного присвоения номеров документам). Этот флажок установлен для всех типов операций в сценариях SAP Customer Relationship Management (SAP CRM) в системном ландшафте SAP Solution Manager. (Другими словами, для модулей Issue Management, Service Desk и ChaRM требуется определить значения диапазона номеров.) Таким образом, если используется диапазон номеров, флажок “Early No. Assgt” устанавливается автоматически. Если этот флажок установлен, бизнес-операции присваивается идентификационный номер независимо от того, будет она сохранена пользователем или нет. Далее рассмотрим шаги, которые необходимо выполнить для деактивации этой функции.

Оформите подписку sappro и получите полный доступ к материалам SAPPRO

У вас уже есть подписка?

Войти

Обсуждения Количество комментариев2

Комментарий от  

Кирилл Сатарин

  |  08 сентября 2010, 17:46

Прекрасная очень понятная статья, именно в формате рекомендации. С её помощью решается одна небольшая проблема и все больше ничего. Побольше бы таких статей с как можно большим количеством описания маленьких простынх настроек, которые приводят к очевидному и полезному результату.

Комментарий от  

Олег Точенюк

  |  20 сентября 2010, 16:52

Решение описанное в статье не учитывает такую вещь как несколько инстанций (серверов приложений) при подключении к серверу базы данных, что в принципе возможно и бывает (при использовании SolMan возможно реже), а при такой ситуации данный метода может давать не верные результаты, так как для нумерации скорее всего включена буферизация (без нее возможны проблемы производительности и конфликты при доступах к таблице интервалов). При включенной буферизации каждая инстанция берет по диапазону номеров в момент старта в локальный буфер и выделяет номера по требованию подключенных клиентов. Обычно буферизация настраивается на 10 номеров, следовательно имеем картину:
1 инстанция получит номера: 0001 - 0010
2 инстанция получит номера: 0011 - 0020
При запросе номера, по первой инстанции будет сгенерирована заявка с номером 1, а при запросе номера по второй инстанции будет получен номер 11. При этом если пользователи первой инстанции более активные, то их диапазон исчерпается раньше и они получат новый в интервале с 0021 - 0030, так что уже имеем погрешность в среднем на величину размера локального буфера номеров для инстанции. Далее при перезагрузке системы не использованные номера не возвращаются, т.е. система зафиксирует последний используемый номер, пусть это будет 0030 из первой инстанции, а во второй пусть были выбраны только 5 номеров с 0011 - 0015, так вот при загрузке инстанции получат номер с 0031 - 0040 и с 0041 - 0050, т..е. каждая получит по следующему десятку номеров.
 
В общем виде, я бы считал номера заявок используя SELECT COUNT(*) FROM <таблица> WHERE <Условия> в с каком-нибудь отчете. Все остальные способы исходя из реализации работы с диапазонами номеров в SAP, будут давать погрешности в оценке количества документов/записей.