Механизм правил Drools или любой другой механизм правил, подходящий для этого требования.

Я работаю над этим проектом, где моя роль заключается в разработке службы, которая использует стандартный xml медицинского страхования. Служба должна выполнять проверки различных полей xml, что включает сравнение данных xml с данными в таблицах базы данных. На данный момент мы предполагаем, что проверки остаются одинаковыми для всех страховых компаний. Но я сомневаюсь, что он останется прежним и может иметь разные требования к валидации для каждой компании. В этом случае рекомендуется использовать механизм правил Drools и разработать файл drl для каждой компании, а также использовать механизм правил для проверки xml.


person pavanlapr    schedule 06.11.2012    source источник
comment
Надеюсь, я понял ваш вопрос. Дай мне попробовать. Я бы сказал, что ваше решение заключается в правильном дизайне. Поскольку вы не спрашиваете совета по дизайну, а для того, какой инструмент лучше всего подходит в качестве механизма правил в наши дни, я бы, вероятно, пошел на слюни, потому что он широко используется и разрабатывается, и легче найти как опытных разработчиков, так и хорошую документацию.   -  person Christian Achilli    schedule 06.11.2012
comment
Мне нужно проверить входящие данные. Данные могут меняться в зависимости от компании. Подходит ли Rule Engine для проверки данных. Нужно ли нам иметь файл drl для каждой компании..   -  person pavanlapr    schedule 06.11.2012
comment
Да, это. По сути, механизм правил говорит вам, что делать, а не как делать. концепция «что делать» аналогична валидации. Как вы сказали, вы можете сделать drl для каждой компании или расширить некоторые общие drl для компании, которая имеет какое-то исключение из основного потока. Для проверки просто вставьте объект, например логическое значение, в рабочую память и проверьте, является ли объект истинным или ложным. Это один из способов, вы также можете подумать о том, что лучше работает в вашей ситуации.   -  person Christian Achilli    schedule 06.11.2012
comment
Вам нужно прояснить несколько вещей, прежде чем принять решение об использовании Drools. Сколько у вас правил проверки? Вам нужно управлять этими правилами из центрального репозитория? Каковы ваши требования к производительности? Насколько сложный у вас домен? Кто будет писать правила проверки?   -  person ali köksal    schedule 07.11.2012
comment
Извините, я пропустил ваш вопрос. На данный момент правил проверки немного, например, 6 проверок для этого сервиса. Ожидается, что правила будут расширяться, поскольку мы будем использовать один и тот же xsd для большего количества сервисов. Я планирую иметь один файл правил для службы. Я буду писать эти правила, и никакие бизнес-аналитики не будут над этим работать.   -  person pavanlapr    schedule 10.11.2012


Ответы (1)


Одним из возможных способов решения этой проблемы было бы сначала проанализировать каждый из файлов, специфичных для компании, в общий формат (промежуточное представление), файл xml, который может быть вашим собственным стандартом выражения данных файлов, которые вы проанализировали ранее.

А затем напишите файл механизма проверки для этого конкретного промежуточного формата.

Если вы сделаете это, то сможете обойтись одним файлом, в котором определены все ваши правила проверки, вместо того, чтобы иметь отдельные файлы для всех разных компаний.

person ssb    schedule 06.11.2012
comment
Не уверен, что понял ваш ответ. XML-схема одинакова для всех компаний. Просто одна компания может не заполнить определенное поле, а другая компания может его отправить. - person pavanlapr; 06.11.2012
comment
о, ладно... Я думал, что у каждой компании есть отдельная схема: P. Тогда единственный способ, который я могу придумать, - это добавить все файлы xml, которые у вас есть, в новый файл в качестве дочерних узлов, каждый из родительских узлов которых представляет компанию, которой они принадлежат. Благодаря этому вы сможете указать все свои правила в одном файле. - person ssb; 06.11.2012