Я могу быть немного многословным, поэтому я заранее извинюсь за это. И может показаться, что я бродил, но в конце я попытаюсь собрать его вместе.
Как я уже сказал в своем ответе на ваш первый вопрос, Возьмите значение из FieldA, отправьте в функцию db, верните значение в FieldB , вызовите хранимую процедуру (или хранимую функцию или что-то еще) из сценария автоматизации это не "хорошая" практика. Это не означает, догматически, что это не должно быть сделано, но, как правило, этого следует избегать. Если исключение из правила передового опыта является лучшим способом решения конкретной проблемы, в вашем коде должно быть указано, почему вы решили (или были вынуждены) сделать исключение. И я поддерживаю этот ответ на ваш первый вопрос, который не упомянул об особых обстоятельствах.
Если в Maximo нет готовых опций конфигурации для того, что вы хотите, например, кроссоверы, отношения, домены и т. Д., То вашим следующим вариантом должны быть параметры настройки внутри продукта (также известные как " небольшие 'c' настройки), если они существуют. Случается так, что в случае Maximo у вас есть "сценарии автоматизации" или "автоскрипты" в Python или JavaScript, со всеми (Java) классами в пути к классам JVM / server в вашем распоряжении (возможно, включая методы класса Java Maximo Spatial) для опции настройки внутри продукта. Используя примеры из Maximo 76 Scripting Features , вы даже можете понять, как вызывать API-интерфейсы RESTful, например, предоставляемые ArcGIS ESRI, по HTTP или HTTPS.
Если настройки внутри продукта (маленькая буква "c") не работают недостаточно хорошо (например, вызывают проблемы с производительностью), то, как правило, допустимо, хотя и не поддерживается, настраивать сам продукт (иначе большой "C" настройки). (В целом приемлемо, так как многие компании примут это обоснование для разработки большой настройки "C", но не поддерживаются, так как поставщик попросит вас удалить вашу настройку и воспроизвести вашу проблему, если проблема обнаружена и если она вообще возможна что ваша кастомизация может каким-либо образом способствовать возникновению проблемы.) В случае Maximo написание ваших собственных классов Java или хранимых процедур обычно считается большой "C" настройкой.
В случае Maximo, и вы, вероятно, можете обобщить это для любого продукта COTS, обновление данных Maximo из хранимой процедуры считается исключительно плохой практикой. Это связано с тем, что такие обновления не подчиняются бизнес-правилам и логике Maximo, что может привести к проблемам с целостностью данных, проблемам поддержки и многим другим. В частности, триггеры часто предполагают, что Maximo произвел обновления базы данных в определенном порядке (например, родительские данные вставляются перед дочерними данными), когда в документации прямо отказывается от приверженности такому порядку. (Если это больше не так, раньше).
С учетом всего этого, если Maximo не предоставляет готовую конфигурацию для того, что вам нужно, и если вы не можете использовать автоскрипты, чтобы делать то, что вы хотите, даже имея доступ ко всем библиотекам Maximo и Java (в таком порядке предпочтения), тогда было бы приемлемо использовать сценарий автоматизации для вызова функции базы данных, чтобы вычислить значение для хранения через Maximo. На самом деле, в этом сценарии вызов функции из вашего скрипта был бы намного лучше, чем установка значения для триггера, потому что, если вы обновите Maximo через его API, такой как mbo.setValue("attribute","value"), ваш скрипт все равно выйдет из аудита, безопасности , проверка, целостность данных и другие бизнес-правила в действии. В качестве бонуса, любые профессиональные консультанты Maximo (такие как я), которых вы привлекаете для помощи в проектах, будут тратить меньше времени (читай: ваши деньги), пытаясь выяснить, что вы делаете и почему, чтобы они не сломали это.
Надеюсь, это поможет.