Сегодня я впервые открыл SAP SuccessFactors Provisioning & Instance. Морально готовьтесь, буду писать, ругаться, материться, потом хвалить, потом перейду на еще что-нить. Это такая эволюция у человека, который долго сидел на одной траве, а затем жизнь подкинула другую.
Итак, стоит учебная задача по созданию своего предприятия в Employee Central (EC), найма пары человек. Нужно научиться создавать свои объекты, связывать их с оргструктурой и людьми (по-нашему, это создавать свои инфотипы). Все версии последние, муха не сидела.
Так вот, я убил 4 часа, чтобы создать свой объект и присоединить его к оргструктуре, к позициям. Я глупый, я понимаю. Но создать-то я его создал минут за 5. А потом включилось программистское мышление, когда связи нужно создавать двусторонние. Как в оргменеджменте есть A и B, вверх и вниз. Так и в реляционных СУБД есть внешние ключики и JOIN таблички. В любом нормальном языке программирования связи настоятельно рекомендуют создавать двусторонними. Здесь оказался «гладиолус» (с) КВН.
Так вот, опытным 4-ех часовым путем выяснилось, что если создавать объект с типом временной привязки From Parent, то к нему нельзя создать данные в Manage Data меню. Система банально не видит его.
Что я делал. Я хотел создать объект особых условий труда согласно Спискам 1 и 2 в РФ. На них прицепить процент вредности, который потом будет наследоваться на человека для расчета зарплаты. Для этого нужно создать отдельный MDF объект в Configure Object Definition, а затем связать его с объектом Position. Как будто штатная позиция ссылается на объект Hazar Work Conditions.
Пока не поменял на Basic, ничерта не появлялось в поиске. Поменять этот параметр просто так нельзя. Удалить объект, если у него есть данные тоже нельзя. В документации про этот параметр написано примерно так: «Лучше всегда ставьте Basic или None». Звучит как «мы сами пока не разобрались, поэтому не тыкайте сюда лучше».
Убиться можно.
Дальше создаем пиклист (выпадающий список) для типа предметов, которые компания нам выдала во временное пользование.
Создаем теперь MDF объект cust_belongings, чтобы в нем хранить выданные принадлежности. Причем в поле cust_pBelongings указываем тип Picklist, а по кнопке Details в Valid Values Source прописываем наш пиклист (дурацкое название) = cust_pBelongingType.
Теперь в объекте Position нужно сделать связи вот таким образом:
Попробуем создать позицию. Для этого открываем в меню Manage Data объект Position. Заполняем все сверху вниз. А внизу мы видим наши две связи. Добавляем условия труда:
Тут все хорошо. А если нажать на принадлежности (Belongings), то будет бяка. Система будет наполнять справочник принадлежностей данными со всех позиций, а это неверно. Нам нужно сделать просто поля, которые будут брать из справочника вид имущества, вручную вводить инвентарные номер и все. Что-то я не так сделал в объектах 😉 Пошли вторые 4 часа.
Так, все переделываем.
В объекте Belongings убиваем поле cust_pBelongings, которое ссылается на список. И цепляем список на поле externalCode:
В этом же объекте меняем временную привязку на зависимую от родителя:
И в самой позиции правим тип соединения.
Дышите, не дышите, не дышите…
Получилось. Заголовки можно переименовать, это легко. На это простое задание у меня ушло около 4 часов и 5 минут. Плюс 10 минут на заметку. При средней ставке консультанта моего уровня в США в 120 долларов, я только что потратил примерно 500 долларов, а вы их сэкономили 😉
Продолжать такие же опусы про SF?
2 комментария
Calm
>>В любом нормальном языке программирования связи настоятельно рекомендуют создавать двусторонними.
Без обид, но,
во-первых, связи создаются в БД, а не «в языке программирования». Это вопрос алгоритмов, но не языка программирования.
во-вторых, таких рекомендаций за 20 лет ни разу не слышал. Подскажите пожалуйста источники настоятельных рекомендаций?
VirVit
Видимо погорячился с настоятельностью. Про СУБД я ничего не скажу, давно уже на уровне базы не работал, не программировал. Современные языки сами объектную модель складывают в базу, делают миграции. Из последнего, с чем я работал, это Rails, где во-многих примерах делаются именно двусторонние связи для контроля целостности при удалении/изменений связей или объектов. Плюс это облегчает поиск зависимых объектах при низкой цене реализации и хранения.
Собственно к чему я придираюсь, так это к реализации таких вещей в SF. Прошлый век, к сожалению, и неудобно.