Думается, что речь идет о создании/управлении признаками через транзакцию CT04. Вы можете указать длину признака, возможные значения, а также можете "прикрутить" даже функциональные модули проверки.

При создании точек измерений/документов измерений система воспринимает только признаки с цифровым форматом. В статье указано, что ...Измеряемый параметр может быть логической величиной (да/нет, плохо/хорошо). Как это возможно поднастроить?

sapland.ru/kb/articles

Вот бы пример такой посмотреть...

Связь между контроллером и представлением можно ослабить:
1. В контроллер передавать интерфейс представления.
2. Интерфейс представления должен содержать: метод для отображения представления; события взаимодействий с пользователем; контекст (часть модели для отображения).
3. В контроллере нужно реализовать события представления.
4. В конструкторе контроллера нужно подписаться на события представления и связать модель с контекстом представления.

Вячеслав, рекомендации выключить iptables и отключить SELinux основаны на личном опыте или на официальных рекомендациях вендора?

Однако классные консультанты, буферизацию сами включают :-), я как-то думал, это не задача функционального консультанта. Но вы расширили мой кругозор редкими экземплярами. Не знал про таких.

Олег, доброго дня.
Абсолютно согласен, абапер может уложить систему так что базиснику не снилось. Но и консультанты имеют возможности попортить жизнь.
Ни кому не сказав, включает буферизацию на Z-таблицу размером 30ГБ с документами, со словами "а мне **** сказал, что так быстрее". Результат я думаю понятен. Или другой, включил заполнение инфраструктуры на выходные, логи за пару часов забили директорию в которой был 3-х кратный запас, система встала. Для справки, она в результате была 780ГБ. Ещё вариант: включили параллельную обработку, уже не вспомню деталей, всё бы ничего, вот только одновременно этот процесс запускали 30 человек, и рабочих процессов под такую нагрузку не было предусмотренно. Объяснение такое же простое: "на DEV и QAS у меня всё работало".
Список можно продолжать. У каждого свои истории.

====
как производимые ими настройки и разработки могут повлиять на работоспособность системы в целом
====
Да никак, на то она и настройка, это вы ведь не про абаперов писали? Абаперы те да, положить систему могут быстро и качественно :-)

все ж было б неплохо указать в статье, что не стоит параллелить пока не выжали все из последовательной обработки. А то находятся последователи индуских талмудов, так напараллелят, что другие процессы стоят.
 
Пример в статье идеальный, 20 задач, 9 параллельных процессов, задача грузит только CPU, поэтому отлично подходит для параллезации. Получили шикарный прирост производительности 80/12 ~= 6,7 раз. Реальный пример, от Олега дает всего лишь 20 632 688/11 520 002 ~1,79 увеличение, при 3-х кратной парализации.
Лучше вначале разобраться, где у вас узкое место и почему оно именно настолько узкое. Иначе есть риск наткнуться на "бо-бо" в продуктивной системе, после "новаторской" оптимизации.

Чего-то у меня цифры не бьются. Например на установку статуса пусть уходит 1 секунда, и время закрытия 5 часов итого за это время при последовательном закрытии у тебя закрывается 5 * 3600 = 18 000 заказов. После распараллеливания, заказ как зарывался за 1 секунду так и будет закрываться, что его параллельно, что последовательно грузить (бапишке фиолетово она в своем процессе отработает необходимое ей время как ты ее не крути). По твоим словам, теперь это все стало отрабатывать за пару минут, ну пусть это будет 5 минут для ровности. Итого у тебя каждую минуту закрывается сколько? Правильно 3600 / 5 = 720 заказов. Короче я в своей жизни систему с 720 свободными процессами не видел еще, твоя видимо первая будет, ну это чтобы оно таки за пару, точнее 5 минут отработало. В общем если бы была реальная статистика с рабочей системы приведена, было бы чуть интереснее. В свое время когда такое делал я просто привел цифры, чтение 120 000 документов:
 
Паралельно 3 процесса: 11 520 002 милисекунд
Последовательно : 20 632 688 милисекунд
 
А ну и сейчас перформы уже не модно Василий К. придет будет говорить, что это не правильное программирование :-), на классах параллельность выглядит чуток интереснее и красивее в реализации, программа обработки выглядит типа так:
LOOP AT <по каким-то объектам которые надо обработать>.
lcl->read( ).    "Прочитали что надо обработать в процесе
lcl->process( ). "Запустили процесс обработки
lcl->wait( ).    "Ждем если нет свободных процессов, иначе идем на следующий шаг.
ENDLOOP.

Статья замечательная. Но хотелось бы подробнее узнать по настройке проводок.