Rozszerzalność synchronizacji danych z POS – opcja 2

Eksport na POS

Istnieje możliwość synchronizowania danych niepowiązanych z obiektami powstającymi na POS i synchronizowanymi do systemu ERP. W tym celu należy wykorzystać procedurę Synchronization.ExportCustoms. Należy pamiętać o zachowaniu struktury w ciele procedury <Customs><Custom>, natomiast struktura pod węzłem <Custom> jest w pełni dowolna.

Warto aby struktura tabel, z której wybieramy dane do przesłania, miała postać drzewiastą, a główna tabela posiadała kolumny:

• GUID – zapewni identyfikacje obiektu miedzy POS i ERP
• Id – do relacji w strukturze
• Type – jeśli chcielibyśmy rozróżniać dane na DSie, tym bardziej gdy istniałyby osobne doróbki
• WasSentToERP – aby odfiltrowywać dane które zostały już wysłane

Oznaczanie wysłanych danych

Istnieje możliwość wykorzystania standardowej metody do oznaczania wysłanych obiektów, aby oznaczać obiekty niestandardowe.
W tym celu przeciążamy metodę serwisu ISynchronizationRepository (ten obszar nie posiada punktów rozszerzeń)

public class SynchronizationRepositoryExt : SynchronizationRepository
{
   public override void MarkIfWasSentToERP(string xml)
   {
      base.MarkIfWasSentToERP(xml);

      using (var context = new POSDBContext())
      {
         context.ExecuteProcedure("Synchronization.MarkSentCustomData", xml);
      }
   }
}

Wewnątrz możemy np. wywołać procedurę, która oznaczy wysłane obiekty.

CREATE PROCEDURE [Synchronization].[MarkSentCustomData]
	@p0 xml
AS
BEGIN
	UPDATE CustomSchema.CustomRootTable
	SET WasSentToERP = 1
	Where GUID in (SELECT xmlData.Col.value('@GUID','varchar(max)') FROM @p0.nodes('/Customs/Custom') xmlData(Col))
END
GO

Przykład eksportu

CREATE PROCEDURE [Synchronization].[ExportCustoms] 
AS
BEGIN
	SET NOCOUNT ON;

	select
		pad.GUID 			as [@GUID],
		pad.Type as [@Type],
		pad.Data1 		as [@Data1],
		Synchronization.GetDatetimeString(pad.ChangeDate) 							as [@ChangeDate],
		(
			select			
td.Number 			as [@NumberString], 
td.Status	 			as [@Status], 
td.Value 				as [@Value]
			from 				CustomSchema.Table1 td 			where pad.Id = td.RootId
			for xml path('Table1'), root('Tables1'), type
		),		
		(
			select				
ti.ToPayNet 				as [@ToPayNet], 
				ti.Points				 as [@Points], 
ti.ToPay				as [@ToPay]
			from 			CustomSchema.Table2 ti 			where 								pad.Id = ti.RootId
			for xml path('Table2'), root('Tables2'), type
		)

	from CustomSchema.RootData pad
	where pad.WasSentToERP = 0

	for xml path('Custom'), root('Customs')
	
END
GO

Import po stronie DataService

Import danych odbywa się z wykorzystaniem serwisu IDataCustomService, i przeciążeniu metody SaveCustom. Metoda jako argument dostaje każdy wiersz Custom w postaci obiektu XElement.

Aby obsłużyć wiele dorobek należy wykorzystać punkty rozszerzeń dla DataService.

Snippet do importu

[DataServiceBusinessModule]
public static class Module    
{
   [MethodInitializer]
   public static void Initialize()        
   {
       var dataCustomService = IoC.Container.Resolve<IDataCustomExtensionPointService>();
       dataCustomService.OnSaveCustomEvent += DataCustomService_OnSaveCustomEvent;
   }
   private static void DataCustomService_OnSaveCustomEvent (object sender, XEEventArgs e)
   {
   //deserializacja + zapis danych
   }
}