Цитата:
Сообщение от
belugin
Я думаю, вот эта фраза относилась к тому, что может просто взять, заполнить контракт самостоятельно и запустить операцию. В случае runBase для этого, надо, чтобы сначала автор кода специально придумал и выставил наружу API
Именно так.
Цитата:
Сообщение от
trud
ну да, в контроллере. Для PurchFormLetter это происходит неявно, в методе construct. причем в методе getDataContractObject
Хотя может это и кривизна конкретной реализации PurchFormLetter, но недавно мы много дней потеряли на поиски этой баги, когда у некоторых пользователей подставлялись старые значения при запуске разноски из кода
Мда, занятно... для прошлых версий, когда создавались наследники RunBase, было хорошим тоном делать для них статический construct(), где после new() еще вызывать getLast(). Смысл был в том, чтобы в стороннем коде можно было дернуть construct(), получить экземпляр класса и при необходимости спокойной выполнять дополнительную инициализацию его через parm-методы, не боясь, что внутри prompt() он все ваши труды перезатрет из SysLastValue. Возможно, разработчики PurchFormLetter в 12-ке решили пойти схожим путем - хотели, как лучше...
Цитата:
Сообщение от
trud
Обычно там делают заполнение параметров от query или наоборот - query от параметров. query кстати в датаконтракт не входит, т.е. ее дополнительно нужно будет передавать.
Я, может, как-то не так готовлю SysOperation framework, но при необходимости я не гнушаюсь добавлять в DataContract параметры типа Query. Да, при этом нужно делать дополнительную валидацию контракта на предмет передачи "кривого" Query, в котором отсутствуют ожидаемые DataSource'ы. Да, при этом нужно делать некий метод, создающий "Query по умолчанию" - либо в контракте, либо в сервисе. Да, такой вариант в AX 2012 не подходит для сервисов, вызываемых через AIF по http, потому что там DataContract должен быть вообще без малейшей бизнес-логики и ссылок на посторонние типы и классы (хотя это - скорее "особенности" публикации AIF'ом сервисов на IIS). Но в целом, если нужно создать сервис, принимающий на вход Query и запускаемый пользователем интерактивно, а не извне через http, по-моему, Query вполне себе может быть частью контракта. Или речь про какие-то стандартные контракты, а не "вообще"?..