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

«Пейзаж после битвы»
Александр Горбульский:
Часто интегратора выбирают по наличию опыта проектов в том бизнесе, который ведет заказчик.  Отзывы об успешности проекта часто исходят от ПМ клиента - лица заинтересованного, а вот...
«Ста­нда­рти­за­ция те­сти­ро­ва­ния и повышение на­де­жно­сти решений за счет инте­гра­ции SAP Solution Manager и SAP Quality Center by HP»
Кирилл Сатарин:
Хорошая статья, дает прекрасное понимание того, как работает взаимодействие между Solution Manager и HP SAP Quality Center. К сожалению авторы не указывают какую именно выгоду можно получить от...
«На­стра­и­ва­ем SLD, MOPZ, EWA в Solution Manager»
Андрей Тимофеев:
Не понятно, для какой версии Solution Manager данное руководство. Если для 7.0, то не актуально.

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

Натан Уильямс
1635
2

При открытии бизнес-операции в 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” устанавливается автоматически. Если этот флажок установлен, бизнес-операции присваивается идентификационный номер независимо от того, будет она сохранена пользователем или нет. Далее рассмотрим шаги, которые необходимо выполнить для деактивации этой функции.

Вы хотели бы увидеть полную версию статьи?

Если вы являетесь подписчиком журнала SAP Professional Journal, пожалуйста, введите в правом верхнем углу логин и пароль.

Если вы хотите подписаться на журнала SAP Professional Journal, пожалуйста, обратитесь в редакцию или сделайте заказ на сайте.

Правила получения тестового доступа к статьям SAP Professional Journal

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

Кирилл Сатарин (Рейтинг: 979) 17:46, 08 сентября 2010

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

Олег Точенюк (Рейтинг: 10169) 16:52, 20 сентября 2010

Решение описанное в статье не учитывает такую вещь как несколько инстанций (серверов приложений) при подключении к серверу базы данных, что в принципе возможно и бывает (при использовании 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, будут давать погрешности в оценке количества документов/записей.

Любое воспроизведение запрещено.
Копирайт © «Издательство ООО «Эксперт РП» Copyright © 2010 Wellesley Information Services. All rights reserved.