Сообщения, отправленные пользователем: shmuylovich

В GetStockEntryListOperation меняется.
Get....ChangesListOperation попробую, спасибо.

Немного прояснилось с фильтром по дате.
Да, как я и догадывался, createDate - это все-таки не дата создания записи, а дата создания версии. А editDate - не дата редактирования, как было бы логично предположить, а дата создания последней актуальной записи.
Таким образом, получив список актуальных записей журнала, вам нужно каждую раскрутить до первой версии, чтобы получить реальную дату создания.
А фильтр таки работает правильно, но не по дате создания первой версии, а по дате создания актуальной версии.

С таким набором параметров инструмент крайне перегружает шлюз и делает алгоритмы запутанными.

dk wrote:Не ломайте голову как бы вы не извращались с датами и т.п. избавится от APLM012 не получится. Её можно победить только повторными запросами, пока не получите результат.
Мы пришли к выводу, что ошибка возникает от загрузки самого шлюза, если очередь из запросов на шлюзе образовалась больше какого-то значения, то идёт APLM012, пока очередь не уменьшится.

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

А так приходится постоянно прогружать весь массив записей! Это же чистое безумие!

Кто-то использует метод GetStockEntryChangesListOperation

Спасибо, попробую.

serg882 wrote:Зачем указываете период создания? Если вам просто нужно получить все записи, то период можно не указывать.

Как я уже писал, мы рассматривали два варианта сокращения объемов загрузки - по периоду или по смещению (офсету). Ни тот, ни другой способ нормально не работают.
Кстати, техподдержка рекомендует запрашивать интервалом не больше 1 суток.

Там у них какая-то путаница в терминологии. Оказывается, receiptDateInterval фильтрует не по дате создания, а по дате обновления. Но и это не все. В поле createDate, судя по всему, выводится не дата создания записи, а дата редактирования (ата создания актуальной версии). Пока это не точно, нужно проверять и анализировать.

При попытке получить список записей журнала продукции, естественно, получаем ошибку APLM012.
На данный момент прогрузилось ~7000 записей из примерно 10000.
Пытались разными способами оптимизировать выборки, чтобы не грузить лишние данные.

Были такие варианты:

1) Запрашивать данные за небольшой период(неделя - месяц) с использованием фильтра receiptDateInterval.
Не получилось добиться корректной работы фильтра. Выяснилось, что, во-первых, правильно работает только параметр beginDate.
А endDate отрабатывает как-то странно. Например, запрашиваю данные за 2 декабря. Получаю какую-то странную выборку с некоторыми (не всеми) записями, созданными 2 - 18 декабря.
Причем у меня в базе записей, которые проскочили между ошибками, уже гораздо больше.

На всякий случай прикладываю текст запроса в xml, может кто заметит ошибку:

<Envelope xmlns="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
	<Body>
		<submitApplicationRequest xmlns="http://api.vetrf.ru/schema/cdm/application/ws-definitions">
			<apiKey>*********************************************************************</apiKey>
			<application xmlns="http://api.vetrf.ru/schema/cdm/application">
				<serviceId>mercury-g2b.service:2.1</serviceId>
				<issuerId>***********************************</issuerId>
				<issueDate>2019-05-29T11:24:22</issueDate>
				<data>
					<getStockEntryListRequest xmlns="http://api.vetrf.ru/schema/cdm/mercury/g2b/applications/v2">
						<localTransactionId>69ea5614-a48e-4418-9931-1a8f836ab1d8</localTransactionId>
						<initiator xmlns:d7p1="http://api.vetrf.ru/schema/cdm/mercury/vet-document/v2">
							<d7p1:login>*********************</d7p1:login>
						</initiator>
						<listOptions xmlns="http://api.vetrf.ru/schema/cdm/base">
							<count>100</count>
							<offset>0</offset>
						</listOptions>
						<enterpriseGuid xmlns="http://api.vetrf.ru/schema/cdm/dictionary/v2">*****************************</enterpriseGuid>
						<searchPattern xmlns:d7p1="http://api.vetrf.ru/schema/cdm/mercury/vet-document/v2">
							<d7p1:blankFilter>ALL</d7p1:blankFilter>
							<d7p1:receiptDateInterval xmlns:d8p1="http://api.vetrf.ru/schema/cdm/base">
								<d8p1:beginDate>2018-01-01T00:00:00</d8p1:beginDate>
								<d8p1:endDate>2019-01-31T23:59:59</d8p1:endDate>
							</d7p1:receiptDateInterval>
						</searchPattern>
					</getStockEntryListRequest>
				</data>
			</application>
		</submitApplicationRequest>
	</Body>
</Envelope>

2) Пытались записывать, в какой пачке пришли правильные записи, т.е. записывали параметры offset и Индекс в выдаче для каждой полученной записи.
А потом пытались делать запросы только для пропущенных пачек. Каково же было мое удивление, когда оказалось, что записи выдаются каждый раз в новом порядке.
То есть то, что мне выдали в одном запросе с офсетом, например 1000, не совпадает с тем, что выдается с таким же офсетом в другом запросе.

Вопрос - я не ошибаюсь? Может я чего-то не учитываю?