Workiva kundestøttesenter

Oversikt

Denne serien om «ledende praksis» skisserer anbefalte generelle fremgangsmåter for ulike artefakter i Data Management Suite i Workiva-plattformen. Husk at dette er generelle retningslinjer og kan måtte tilpasses basert på spesifikke, unike brukstilfeller. Disse anbefalingene har som mål å hjelpe deg med å forbedre organiseringen i arbeidsområdene dine. La oss begynne med å utforske disse navnekonvensjonene.

Navnekonvensjoner for Tilkoblinger, Kjeder og Miljøer

Forbindelser i kjeder

Når du oppretter koblinger i kjeder, er det viktig å etablere optimale navnekonvensjoner for å sikre klarhet og skille mellom Miljøer:

• Navn på kontakt: Gi kontakten et beskrivende navn som tydelig angir dens formål og funksjon.
• Type arbeidsområde: Angi arbeidsområdet eller prosjektet der koblingen brukes.
• Miljøet til koblingen: Identifiser tydelig miljøet (f.eks. utvikling, produksjon) som koblingen tilsvarer.

Eksempel:

• SFTP-tilkobling | SEC-rapportering | IKKE-PRODUKT
  • Beskrivelse: Oppretter en forbindelse til SFTP-serveren for en SEC-rapporteringsløsning i et ikke-produksjonsmiljø som utvikling, kvalitetssikring, sandkasse osv.
• SFTP-tilkobling | SEC-rapportering | PROD
  • Beskrivelse: Oppretter en forbindelse til SFTP-serveren for SEC-rapporteringsarbeidsområdeløsningen i produksjonsmiljøet.

Denne navnekonvensjonen forenkler identifisering og administrasjon av tilkoblinger på tvers av forskjellige miljøer. Det sikrer at kjeder innenfor spesifikke miljøer kun samhandler med de riktige kildene, noe som forbedrer sikkerhet og pålitelighet. En Ikke-produksjons -[]- tilkobling kan utnyttes på tvers av ikke-produksjons-, utviklings- og testmiljøer.

Denne navnekonvensjonen bør brukes konsekvent på alle tilkoblinger, enten de er kjerne- eller premium-tilkoblinger. Ved å opprettholde ensartethet i navngiving av forbindelser på tvers av ulike miljøer, kan du effektivisere kjedepromoteringsprosessen og muliggjøre sømløs utførelse av kjeder på tvers av arbeidsområder.

Kjedesammensetter

Når man bygger kjeder i Workiva-plattformen, er det avgjørende å opprettholde en godt organisert navnekonvensjon. En tydelig og konsekvent navnestrategi bidrar til å navigere i kjedene mer effektivt, spesielt ettersom antallet arbeidsflyter øker. Denne delen skisserer de viktigste fremgangsmåtene for navngiving av kjeder basert på deres formål, kildesystem, frekvens og arbeidsflythierarki.

Formål og kildesystem

Bestemme kjedens formål

Vurder følgende spørsmål for å definere formålet med en kjede:

• Hvilken type data brukes i kjeden?
• Kan kjeden brukes på tvers av flere prosesser (dvs. er det en verktøykjede)?
• Hvilket kildesystem brukes til å hente data fra?

Frekvens

Spesifisering av kjedens frekvens

Når du navngir kjeden, er det viktig å angi frekvensen, spesielt hvis den er planlagt å kjøre automatisk. Vi foreslår følgende retningslinjer:

• Angi om kjeden skal kjøres på ad hoc-basis.
• Spesifiser om kjeden kjører daglig, ukentlig, kvartalsvis eller årlig.

Hierarki

Organisering av komplekse kjedebygginger

I en kjedebygging som består av flere arbeidsflyter, er det vanligvis en kjede på toppnivå med flere underkjeder som kjøres i en sekvens. Organiser disse kjedene ved å gi dem et nummerert navnekonvensjonsprefiks.

Eksempel på en nummerert navnekonvensjon:

• 1.0 Toppnivåkjede
• 1.1 Utfør datasett
• 1.2 Last inn data til Wdata-tabellen
• 1.3 Oppdater innkommende tilkoblinger

Denne tilnærmingen hjelper brukere med raskt å identifisere rekkefølgen på operasjoner i en arbeidsflyt og organiserer automatisk kjedene i arbeidsområdet basert på den numeriske rekkefølgen.

Praktiske eksempler på kjedenavnkonvensjoner

Forsyningskjeder

Verktøykjeder er vanlige arbeidsflyter som utføres av flere andre arbeidsflyter, for eksempel Laste inn data i en Wdata-tabell. For å sikre at verktøykjeder vises tydelig øverst i arbeidsområdet, bør du vurdere følgende navnekonvensjoner::

• 0.0 - [Navn på strømkjede] | [Prosess] | Strømkjede
• 0.1 - [Navn på forsyningskjede] | [Prosess] | Forsyningskjede
• 0.2 - [Navn på strømkjede] | [Prosess] | Strømkjede

Kildesystemer

Begrepet «kildesystemer» refererer til dataenes opprinnelse, som kan omfatte ulike systemer som ERP (Enterprise Resource Planning), EPM (Enterprise Performance Management), HR (Human Resources) og regnskapssystemer, eller det kan være filbasert, som data som kommer fra en SFTP/FTP.

Følgende eksempel viser organiseringen for tre kildesystemer som et eksempel:

1. Arbeidsdag
   • 1.0 - [Kjedenavn/prosess] | Arbeidsdag | [Frekvens]
   • 1.1 - [Kjedenavn/prosess] | Arbeidsdag | [Frekvens]
   • 1.2 - [Kjedenavn/prosess] | Arbeidsdag | [Frekvens]
2. SEVJE
   • 2.0 - [Kjedenavn/prosess] | SAP | [Frekvens]
   • 2.1 - [Kjedenavn/prosess] | SAP | [Frekvens]
   • 2.2 - [Kjedenavn/prosess] | SAP | [Frekvens]
3. Netsuite
   • 3.0 - [Kjedenavn/prosess] | Netsuite | [Frekvens]
   • 3.1 - [Kjedenavn/prosess] | Netsuite | [Frekvens]
   • 3.2 - [Kjedenavn/prosess] | Netsuite | [Frekvens]

For et arbeidsområde med et stort antall kjeder, bruk følgende eksempler på navnekonvensjoner for klarhet og organisering:

Denne strukturen sikrer klare og konsistente navnekonvensjoner og organisering, noe som gjør det enklere å identifisere og administrere forsyningskjeder og kildesystemkjeder basert på prosessen og utførelsesfrekvensen deres.

Miljønavnkonvensjon

Miljøer lar deg enkelt planlegge, teste og distribuere arbeidsflyter. Dette effektiviserer anvendelsen av beste praksis for programvareutviklingslivssyklusen (SDLC) i automatiseringsprosessene dine. Når du oppretter miljøer, foreslår vi at du bruker følgende forenklede navnekonvensjoner for å tydelig identifisere formålet med hvert miljø. Dette hjelper brukerne raskt å forstå den tiltenkte bruken av hvert miljø.

Miljøtyper og navnekonvensjoner

1. DEV (Utvikling)
   • Formål: Brukes til å utvikle nye kjeder og prosesser. Byggere kan trygt opprette og eksperimentere i utviklingsmiljøet (DEV).
   • Eksempel: DEV
2. Test (eller sandkasse)
   • Formål: Dedikert til testing og kvalitetssikringsprosesser. QA-team kan gjennomgå og teste i testmiljøet (Test).
   • Eksempel: TEST
3. PROD (Produksjon)
   • Formål: For prosesser som er testet, forbedret og klare for distribusjon i produksjonsmiljøet. 

   • Eksempel: PROD

     

Merknader

• Flere kjeder kan ha identiske navn, men hver kjede skilles fra hverandre med en unik identifikator kjent som en GUID.

• Hvert arbeidsområde har en unik ID (se i URL-en), slik at flere arbeidsområder kan ha samme navn. Vi anbefaler imidlertid ikke å gjøre det på grunn av potensialet for brukerforvirring.
• Kjeder, arbeidsområde og arbeidsområdemiljø navngir alle støtteområder og Workivas standard tegnsett.
• Navnelengder:
  • Kjedenavn har en maksimal lengde på 100 tegn.
    Forsiktig: når du kopierer kjeder, legges tegnene "-- Kopier" automatisk til. Hvis dette resulterer i et navn som er lengre enn 100 tegn, vil ikke kjeden bli kopiert.
  • Kjedekommandonavn (nodenavn) kan ha maksimalt 255 tegn. 
  • Navn på arbeidsområderhar en maksimal lengde på 50 tegn.
  • Navn på arbeidsområdemiljøerhar en maksimal lengde på 25 tegn.

Sammendrag

Bruk av disse forenklede navnekonvensjonene bidrar til å opprettholde et strukturert og lettnavigerbart miljøoppsett. Det sikrer at formålet med hvert miljø er tydelig, noe som reduserer forvirring og forbedrer effektiviteten i utviklings-, test- og distribusjonsfasene.