Выгрузка измененных клиентов во внешнюю систему

[trud]

Спасибо. Я правда не очень понимаю, как это будет работать,
1 - change tracking он же включится для всей таблицы, получается будет много пустых срабатываний(когда поменялись не нужные нам поля)?
2 - плюс по связям - для примера LOGISTICSELECTRONICADDRESS напрямую с клиентом не связана(связана через несколько таблиц). что в этом случае будет трекаться
3 - как делать горизонтальную фильтрацию, т.е. мне нужны клиенты которые менялись из заданной группы, причем группа может быть разной. Описанный способ после запроса просто помечает весь запрос как использованный

[Vadik]

Цитата:

Сообщение от trud

change tracking он же включится для всей таблицы?

да

Цитата:

плюс по связям - для примера LOGISTICSELECTRONICADDRESS напрямую с клиентом не связана(связана через несколько таблиц). что в этом случае будет трекаться

CT включается для всех таблиц в документе / запросе (AxdCustomer если я правильно помню)

Цитата:

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

через document filters (фильтры правда только на датасорсе "верхнего" уровня можно задавать, т.е. на CustTable но не на адресах)

[Vadik]

вот тут CT достаточно подробно обсуждалось

[trud]

Цитата:

Сообщение от Vadik

CT включается для всех таблиц в документе / запросе (AxdCustomer если я правильно помню)

А как он тогда будет получать то что поменялось? просто адресов там тоже много(17млн).
Клиент уже пробовал реализовать это включением даты модификации на каждой таблице, и запросом где дата модификации фильтруется по ИЛИ для каждой таблицы. Это работает, но медленно, т.е. запрос выполняется больше чем минуту, а таких приходит по десятку в минуту для разных групп
Еще вопрос с ченж трекингом - он живет несколько дней, как быть если они захотят обновить данные полностью (к примеру получить клиентов за последние несколько лет)? писать отдельную обработку?

Пример запроса который они сделали

..
	 INNER JOIN LOGISTICSELECTRONICADDRESS leaEmail
	    ON dplEmail.LOCATION = leaEmail.LOCATION
	   AND leaEmail.TYPE = 2 -- Email
	   AND (leaEmail.VALIDFROM <= @sync_new_received_anchor AND leaEmail.VALIDTO > @sync_new_received_anchor)
	  LEFT OUTER join DIRNAMEAFFIX dna
	    ON dna.RECID = dp.PERSONALTITLE
	   AND dna.AFFIXTYPE = 1
	  LEFT OUTER JOIN (
		   SELECT dpl.PARTY as PARTY, lea.LOCATOR as LOCATOR,
				  ll.MODIFIEDDATETIME as LL_MODIFIEDDATETIME,
				  lea.MODIFIEDDATETIME as LEA_MODIFIEDDATETIME
			 FROM DIRPARTYLOCATION dpl
			INNER JOIN LOGISTICSLOCATION ll
			   ON ll.RECID = dpl.LOCATION
			  AND ll.DESCRIPTION = 'Home' -- Home phone number
			INNER JOIN LOGISTICSELECTRONICADDRESS lea
			   ON lea.LOCATION = dpl.LOCATION
			  AND lea.TYPE = 1 -- Phone
			  AND (lea.VALIDFROM <= @sync_new_received_anchor AND lea.VALIDTO > @sync_new_received_anchor)
			WHERE (dpl.VALIDFROM <= @sync_new_received_anchor AND dpl.VALIDTO > @sync_new_received_anchor)
			) homePhone
		ON homePhone.PARTY = dp.RECID
	  LEFT OUTER JOIN (
		   SELECT dpl.PARTY as PARTY, lea.LOCATOR as LOCATOR,
				  ll.MODIFIEDDATETIME as LL_MODIFIEDDATETIME,
				  lea.MODIFIEDDATETIME as LEA_MODIFIEDDATETIME
			 FROM DIRPARTYLOCATION dpl
			INNER JOIN LOGISTICSLOCATION ll
			   ON ll.RECID = dpl.LOCATION
			  AND ll.DESCRIPTION = 'Mobile' -- Mobile phone number
			INNER JOIN LOGISTICSELECTRONICADDRESS lea
			   ON lea.LOCATION = dpl.LOCATION
			  AND lea.TYPE = 1 -- Phone
			  AND (lea.VALIDFROM <= @sync_new_received_anchor AND lea.VALIDTO > @sync_new_received_anchor)
			WHERE (dpl.VALIDFROM <= @sync_new_received_anchor AND dpl.VALIDTO > @sync_new_received_anchor)
			) mobilePhone
		ON mobilePhone.PARTY = dp.RECID
	 WHERE c.DATAAREAID = @AXDataAreaId
	   AND c.OWIGUID != '00000000-0000-0000-0000-000000000000'
	   AND c.ONETIMECUSTOMER = 0 -- Don't sync one time customers
	   AND c.CUSTGROUP = @custGroup
	   AND (
			   (c.MODIFIEDDATETIME >= @sync_last_received_anchor AND c.MODIFIEDDATETIME < @sync_new_received_anchor)
			OR (dpn.MODIFIEDDATETIME >= @sync_last_received_anchor AND dpn.MODIFIEDDATETIME < @sync_new_received_anchor)
			OR (leaEmail.MODIFIEDDATETIME >= @sync_last_received_anchor AND leaEmail.MODIFIEDDATETIME < @sync_new_received_anchor)
			OR (dna.MODIFIEDDATETIME >= @sync_last_received_anchor AND dna.MODIFIEDDATETIME < @sync_new_received_anchor)
			OR (homePhone.LEA_MODIFIEDDATETIME >= @sync_last_received_anchor AND homePhone.LEA_MODIFIEDDATETIME < @sync_new_received_anchor)
			OR (homePhone.LL_MODIFIEDDATETIME >= @sync_last_received_anchor AND homePhone.LL_MODIFIEDDATETIME < @sync_new_received_anchor)
			OR (mobilePhone.LEA_MODIFIEDDATETIME >= @sync_last_received_anchor AND mobilePhone.LEA_MODIFIEDDATETIME < @sync_new_received_anchor)
			OR (mobilePhone.LL_MODIFIEDDATETIME >= @sync_last_received_anchor AND mobilePhone.LL_MODIFIEDDATETIME < @sync_new_received_anchor)
		   )

[Vadik]

Цитата:

Сообщение от trud

А как он тогда будет получать то что поменялось? просто адресов там тоже много(17млн)

AIF в runtime генерит запрос который из CT вытаскивает изменения по каждой таблице в Query, их по relations "пристыковывает" к "главной" таблице и объединяет все через UNION. Т.е. одному клиенту поменяли группу, второму отчество, третьему адрес а четвертому - мобильный, но getChangedKeys() увидит и вернет все четыре AxdCustomer документа как измененные. Надежно, удобно, но достаточно затратно чтобы такие трюки раз в минуту на 6М клиентов проворачивать.

Цитата:

Еще вопрос с ченж трекингом - он живет несколько дней, как быть если они захотят обновить данные полностью (к примеру получить клиентов за последние несколько лет)? писать отдельную обработку?

"Измененные данные", "быстро и часто" и "все за несколько лет" это же в некотором смысле требования противоречащие друг другу ? В теории, если изначально реализовано нормально (с поддержкой paging-а), это может работать (но быстро точно не будет), но я бы не бросался за реализацию пока клиент не определился с тем что и как он хочет интегрировать

[trud]

Цитата:

Сообщение от Vadik

AIF в runtime генерит запрос который из CT вытаскивает изменения по каждой таблице в Query, их по relations "пристыковывает" к "главной" таблице и объединяет все через UNION. Т.е. одному клиенту поменяли группу, второму отчество, третьему адрес а четвертому - мобильный, но getChangedKeys() увидит и вернет все четыре AxdCustomer документа как измененные.

А вот этот момент можешь раскрыть подробнее? т.е. в исходном запросе будут outer join для всяких адресов, емейлов и прочего.
Будет ли эта штука(с пристыковываниями) работать с таблицей которая присоединена по outer join(при том что таких таблиц несколько в одном запросе)?