Přejít k obsahu
Integrace7 min čtení

Import nemovitostí z realitního softwaru na web

Makléř zadá nabídku do realitního softwaru a pak ji podruhé přepíše na vlastní web. U desítek nemovitostí s fotkami je to práce na celý den a data stárnou. Popisujeme, jak to vyřešit a kde se to obvykle rozbije.

Dvojí zadávání je drahé jinak, než se zdá

Nejde jen o čas. Jde o to, že obě evidence se během týdne rozejdou. Cena se sníží v portálu, na webu zůstane stará. Nemovitost se prodá, na webu visí dál. Klient volá kvůli něčemu, co už neexistuje, a makléř to vysvětluje.

Pokud realitní software nabízí XML nebo jiné exportní rozhraní, může web nabídky pravidelně přebírat. To je celý základ řešení: web si export jednou za čas stáhne a sám se podle něj srovná. U Spolu v realitách jsme přesně tohle postavili nad exportem z POSKI REAL.

Synchronizace musí jít jen jedním směrem

Tohle je nejdůležitější rozhodnutí a dělá se hned na začátku. Když si obě strany můžou data přepisovat navzájem, dřív nebo později si je přepíšou špatně a nikdo nepozná, která verze je ta správná.

Správně je jedno místo, kde se nabídka edituje, a web, který ji jen zobrazuje. Makléř pracuje tam, kde je zvyklý. Změna na webu se při dalším běhu přepíše a je to tak správně, protože web není evidence.

Než se pustíte do obousměrné synchronizace, ujasněte si, která evidence je ta hlavní.

Duplicity vznikají párováním podle názvu

Klasická chyba: import hledá, jestli už nemovitost existuje, podle nadpisu nebo adresy. Makléř pak upraví nadpis na webu kvůli lepšímu znění a při dalším běhu vznikne druhý záznam. Za měsíc má web tři verze téže nemovitosti.

Párovat se musí podle ID z portálu, nikdy podle textu. ID se nemění a je jedno, co s nadpisem kdo udělá.

Nastavení synchronizace nabídek v administraci WordPressu
Ruční spuštění, testovací běh a statistiky posledního importu. Bez toho se chyba hledá v logu serveru.

Na co si dát pozor jinde

Velikost feedu

Export s pár stovkami nemovitostí a tisíci fotkami umí mít desítky megabajtů. Když se načte celý do paměti, hosting to odmítne. Parsovat se musí průběžně, ne najednou.

Zbytečné zápisy

Když se při každém běhu přepíše všech tři sta nabídek, i když se nic nezměnilo, databáze zbytečně roste a běh trvá minuty. Řešení je otisk obsahu: spočítá se hash, a pokud sedí, záznam se přeskočí.

Obrázky

Bez deduplikace se při každém běhu stáhne tatáž fotka znovu a knihovna médií naroste do gigabajtů. Zároveň musí zůstat pořadí z feedu, jinak se hlavní fotka rozhodí.

Číselníky

Dispozice, stavy a typy nemovitostí přicházejí jako text. Když se nepárují proti skutečné definici polí včetně diakritiky, polovina nabídek skončí bez dispozice a filtr na webu nefunguje.

Jak poznat, že je to udělané dobře

  • Import jde spustit ručně a má testovací běh, který ukáže změny před zápisem.
  • Je vidět, kdy proběhl naposledy a co udělal.
  • Dvě souběžná spuštění si nelezou do cesty.
  • Doplněk jde vypnout a web dál funguje, protože data leží v běžných polích, ne v jeho vlastní tabulce.

Ten poslední bod bývá rozdíl mezi doplňkem, který jde po letech vyměnit, a doplňkem, na kterém web navždy visí. Stejné pravidlo používáme u integrací obecně.

Časté otázky

Jak dostat nabídky z realitního softwaru na vlastní web?

Přes XML nebo jiné exportní rozhraní, pokud ho realitní software nabízí. Web si export v nastavených intervalech stáhne a podle něj srovná své záznamy. Makléř dál pracuje jen v realitním softwaru.

Má synchronizace fungovat oběma směry?

Skoro nikdy. Když si obě evidence mohou přepisovat data navzájem, dřív nebo později se rozejdou a nepoznáte, která verze platí. Jedno místo pro editaci, web jen zobrazuje.

Proč vznikají na webu duplicitní nemovitosti?

Protože import páruje záznamy podle nadpisu nebo adresy. Jakmile někdo text upraví, další běh vytvoří nový záznam. Párovat se má podle ID z portálu, které se nemění.

Zpomalí import web?

Nemusí. Feed se má parsovat průběžně, ne načítat celý do paměti, a záznamy bez změny se mají přeskočit podle otisku obsahu. Běh pak trvá sekundy místo minut.

Co se stane, když doplněk vypneme?

U dobře udělaného řešení nic. Data leží v běžných polích webu, ne ve vlastní tabulce doplňku, takže nabídky zůstanou a přestane se jen aktualizovat.

AutorOndřej Koziorek

Founder a creative director nkz.studio. Vede návrh a značku, vývoj řešíme v nkz.dev.

Probrat projekt
Dál ze zápisků
Rozhodování

Web, e-shop, nebo vlastní aplikace?

Čtyři otázky, podle kterých poznáte, co vlastně poptat.

Přečíst
Zadání

Co musí obsahovat zadání pro aplikaci?

Technické zadání mít nemusíte. Stačí popsat provoz, role a ruční práci.

Přečíst
Cena

Kolik stojí interní systém pro firmu?

Co cenu zvedá, čím začít a jak spočítat návratnost z ruční práce.

Přečíst