Om dataoptimering og ydeevne i Salesforce Spiff

Designer og Kommissionssystem

Designer og kommissionssystemet minder grundlæggende om hinanden, men tjener forskellige formål. Designer bruger kommissionssystemet til at vise beregningsresultater i realtid, ligesom et regneark. Kommissionssystemet beregner erklæringer isoleret med en fast mængde hukommelse og tid allokeret til hver erklæring.

Denne tabel viser nøgleegenskaberne for hver af dem.

Da Designer fungerer under lavere hukommelses- og behandlingsgrænser end kommissionssystemet, er en timeout i Designer et nyttigt signal at undersøge og optimere – men det betyder ikke altid, at erklæringsberegning mislykkes. For mindre konfigurationer angiver en timeout i Designer ofte, at den samme logik vil have problemer ved erklæringsskalaen. For større eller mere komplekse planer kan der forekomme designertimeouts, selv når den ækvivalente erklæring beregnes korrekt.

Når en erklæring overskrider dens hukommelse eller tidstildeling, er der to stier tilgængelige: Kontakt Salesforce Support for at anmode om en ressourceforøgelse eller for at optimere planlogik og datafiltre. I praksis er en ressourceforøgelse ofte den hurtigste løsning, når problemet opdages tæt på en lønkørsel. Optimering håndterer den underliggende årsag og er den anbefalede opfølgning, hvis en ressourceforøgelse alene ikke løser problemet, eller som en langsigtet strategi til at reducere erklæringsressourceforbrug.

Antag f.eks., at du opbygger et beregnet felt på objektet Salgsmuligheder, der bruger en sum()-funktion til at aggregere årlig tilbagevendende omsætning (ARR) på tværs af alle lukkede salgsmuligheder for en sælger. Når du får vist et eksempel på en erklæring i Designer for en enkelt medarbejder med to års historik, udløber beregningen. Hvis der sker en timeout i Designer, har kommissionen det samme problem – og sandsynligvis på en større skala – når den behandler erklæringer for hele din medarbejderpopulation i en enkelt kørsel. Løsningen er at optimere beregningen, før du flytter til produktion: deaktiver sporing på sum() feltet, indkapsle det som en separat regnearksberegning, eller udskift fuld historik scanning med et filtreret dataområde.

Tip Test komplekse beregninger i Designer, før du udruller dem til produktion. Timeouts i Designer er et signal til at undersøge din logik og dine datafiltre, men succes med opgørelsesberegning er produktionsbenchmark. For større planer kan designertimeouts bevares, selvom erklæringer beregnes korrekt.

Hvor du skal fokusere på optimeringsbestræbelser

Ydeevneforbedringer i Spiff kommer fra tre områder: hvordan data indsættes i systemet, hvordan planlogik behandler disse data, og hvilke felter der er konfigureret til at blive vist på erklæringssiden. Hvis du håndterer alle tre sammen, opnås de bedste resultater.

Fokuser dine optimeringsbestræbelser på tværs af disse tre lag.

• Datalag. Optimer datafiltre, reducer registreringsvolumen gennem upstream-filtrering (i kildesystemer), og forstå skemaet og relationer mellem dine objekter. Se Optimer datafilterydelse i Salesforce Spiff og Reducer indlæsning af kommissionssystem med upstream-dataændringer.
• Planlæg logiklag. Indkapsler beregninger, inaktiver sporing, hvor det ikke er nødvendigt, og brug opslagstabeller og dynamisk logik i stedet for hardcodede værdier eller komplekse indlejrede formler. Se Brug indkapsling i Salesforce Spiff-beregninger og Brug opslagstabeller og dynamisk logik i Salesforce Spiff.
• Konfiguration af erklæringsside. Begræns felter på erklæringssiden til, hvad medarbejdere aktivt har brug for at se, og fjern mellemliggende beregninger og diagnostiske felter fra den repræsentative visning. Kommissionssystemet kører hvert synligt felt for hver erklæring – selv felter, som systemet ellers ikke ville støde på i beregningsstien.

Ydelsesprincipper

Husk på disse vejledende principper gennem din implementering.

• Start optimering på dag et, og se den regelmæssigt igen. Tilpasning af forbedringer af ydeevne i en eksisterende konfiguration er vanskeligere end at indbygge dem fra starten. Planlægningslogik og datamængder ændres over tid, så opbyg ydeevnegennemgang i din almindelige planvedligeholdelsescyklus – ikke kun din indledende implementering.
• Konsolider og aggreger data, før de når motoren. Strukturer dine data, så medarbejdere arbejder med et meningsfuldt, administrerbart sæt af forpligtelser – ikke hundredvis eller tusindvis af individuelle registreringer. Aggregering og konsolidering af data opstream, før de synkroniseres i Spiff, reducerer kompleksiteten for både medarbejdere og kommissionssystemet. Hvis du ønsker specifikke teknikker til at kontrollere, hvilke data der synkroniseres med Spiff, kan du se Optimer datafilterydeevne i Salesforce Spiff.
• Forstå dine datamængder over tid. En konfiguration, der klarer sig godt ved start, kan forringes, efterhånden som registreringsantallet øges. Planlæg arkivering, og gennemse projekterede mængder med dit datateam.
• Begræns erklæringssidefelter til det, som medarbejdere har brug for. Hvert felt, der er valgt på erklæringssiden, køres af systemet for hver erklæring, uanset om beregningsstien ellers ville nå den. Fjern mellemliggende beregninger og interne sporingsfelter fra den repræsentative visning.
• Aktiver kun sporing, hvor det tjener et formål. Sporing lagrer data og forbruger hukommelse og beregningstid. Aktiver det for felter, som medarbejdere har brug for at se på deres erklæringer, eller som Comp-administratorer kræver til rapportering. Inaktiver det for mellemliggende beregninger, relationsoversigter og ethvert felt, der ikke skal vises i medarbejdervisninger eller eksporter.
• Undgå hardcodede værdier. Gem variabelbeløb i regnearksfelter, og brug opslagstabeller, så logikken forbliver vedligeholdelsesvenlig, efterhånden som forretningsregler ændres.