Organisere løsninger

Før du oppretter løsninger, må du ta deg tid til å planlegge miljøstrategien og løsningsstrategien. Vurder følgende aspekter:

De følgende avsnittene skisserer tre strategier, ordnet fra det enkleste til det mest komplekse, og fremhever deres respektive fordeler og ulemper.

Strategi for én enkelt løsning

Alle tilpasninger grupperes i én uadministrert løsning under utvikling, som senere eksporteres som én enkelt administrert løsning for distribusjon.

Anbefales for:

• Implementeringer av små og mellomstore skalaer
• Scenarier der fremtidig modulærisering er usannsynlig

Flere løsninger i ett enkelt utviklingsmiljø

Flere uadministrerte løsninger vedlikeholdes i ett enkelt utviklingsmiljø, som hver vanligvis er dedikert til ikke-relaterte funksjoner eller moduler.

Anbefales for:

• Små og mellomstore implementeringer med distinkte og uavhengige funksjonsområder som ikke deler komponenter.

Når du har flere løsninger i samme utviklingsmiljø, oppretter du ofte lag når du har importert de administrerte løsningene til målmiljøet. Hvis du vil ha mer informasjon, kan du se Løsningslag og flettevirkemåte.

Det du trenger å vite før du arbeider med flere løsninger i samme miljø

Følg disse fremgangsmåtene når du arbeider med flere uadministrerte løsninger i ett enkelt utviklingsmiljø:

• Bruk bare én løsningsutgiver. Løsningsutgiveren eier komponentene i en administrert løsning, og tilknytningen kan ikke endres senere. Hvis du for eksempel importerer en egendefinert tabell som administrert gjennom løsning A med Publisher X, kan du ikke senere flytte tabellen til løsning B med Publisher Y. Det eneste alternativet er å slette tabellen, oppgradere løsning A for å fjerne tabellen fra målsystemet, og deretter opprette tabellen på nytt i løsning B med Publisher Y og importere løsning B. Denne fjerningsprosessen fører til tap av alle data som er lagret i den egendefinerte tabellen, med mindre du migrerer dataene på forhånd.
• Bruk én enkelt uadministrert løsning i utviklingsmiljøet. Hvis du trenger å tilpasse en administrert komponent fra en annen administrert løsning, legger du til komponenten i en uadministrert løsning. Hvis du vil tilpasse den administrerte komponenten, må de administrerte egenskapene angis til å kunne tilpasses. Eksporter deretter den uadministrerte løsningen som administrert for distribusjon til andre miljøer. Hvis du vil ha mer informasjon, se Forvaltede egenskaper.
• Hvis du bruker flere løsninger, må du ikke inkludere den samme uadministrerte komponenten i mer enn én løsning.
• Hvis du bruker flere løsninger, bør du bare ha én løsning som inneholder alle tabellene. Ikke ha to forskjellige løsninger der begge inneholder tabeller. Denne betingelsen finnes fordi det ofte er risiko for én enkelt relasjon mellom tabeller, noe som oppretter en avhengighet på tvers av løsninger og forårsaker løsningsoppgradering eller sletting av problemer i målmiljøet på et senere tidspunkt.
• Hvis du bruker flere løsninger, unngå å opprette avhengigheter mellom løsninger. Avhengigheter fremtvinger en importrekkefølge og kan forårsake problemer. Hvis du for eksempel har én løsning for tabeller og en annen for skyflyter, og en flyt er avhengig av en egendefinert kolonne, fungerer den under utvikling fordi kolonnen finnes. Hvis du imidlertid bare importerer skyflytløsningen til målmiljøet, gjenkjenner kanskje ikke importprosessen avhengigheten av den egendefinerte kolonnen. Som et resultat av dette installeres flytløsningen, men flyten fungerer ikke. Hvis du vil ha mer informasjon, kan du se Eksempler på avhengigheter opprettet av flere løsninger.

Hva du bør unngå når du arbeider med flere løsninger i samme miljø

Her er et eksempel der plattformen ikke lar deg avinstallere eller oppgradere noen av de administrerte løsningene fordi de to løsningene fra forskjellige utgivere prøver å oppdatere den samme komponenten. Situasjonen:

• To administrerte løsninger fra forskjellige utgivere er installert i samme miljø.
• Minst én komponent (komponent 1) eies av Publisher A, men utvides av Publisher B. Publisher A-løsningen er det grunnleggende laget for komponenten, og Publisher Bs løsning er på toppen av den.
• Minst én annen komponent (komponent 2) eies av Publisher B og utvides av Publisher A. Denne betingelsen er den inverse av det forrige punktet.

Dette problemet oppstår fordi det oppstår en sirkulær avhengighet for komponenten med begge løsningene, og plattformen lar deg ikke avinstallere eller oppgradere komponenten. I dette eksemplet:

• Sol A kan ikke avinstalleres fordi den eier komponent 1, og det finnes en overliggende tilpasning fra en løsning som tilhører Publisher B. Hvis du vil avinstallere Sol A, må du først avinstallere Sol B.
• Sol B kan ikke avinstalleres fordi den eier komponent 2, og det finnes en tilpasning oppå fra en løsning som tilhører Publisher A. Hvis du vil avinstallere Sol B, må du først avinstallere Sol A.

Eksempler på avhengigheter opprettet av flere løsninger

• Verktøyribber. Når flere løsninger endrer programbåndet eller områdekartet for den samme appen.
• Programtillegg eller skyflyter. Hvis plugin- eller flytutløseren utløser på en egendefinert kolonne eller oppdaterer en egendefinert tabell, er objektet avhengig av de egendefinerte tabellene.
• Sikkerhetsroller. Når det finnes egendefinerte tabeller, avhenger sikkerhetsroller vanligvis av disse tabellene for brukertilgang.

Flere løsninger med flere dedikerte utviklingsmiljøer

Denne strategien innebærer å utvikle hver uadministrert løsning i sitt eget isolerte dataverse utviklingsmiljø. Denne strategien brukes ofte i modulære arkitekturer der for eksempel ulike programmer, for eksempel salg, kundeservice eller felttjeneste, bygges og vedlikeholdes uavhengig av hverandre. En basisløsning som inneholder vanlige komponenter (for eksempel konto- og kontakttabeller) opprettes og distribueres som en administrert løsning i hvert appspesifikke utviklingsmiljø. Hver app har deretter sin egen uadministrerte løsning, lagdelt på toppen av den grunnleggende administrerte løsningen, slik at team kan utvide funksjonaliteten uten å endre grunngrunnlaget.

Anbefales for:

• Store virksomhetsprosjekter.
• Teams med flere utviklere eller partnere
• Scenarioer som krever streng styring og CI/CD-datasamlebånd.

Slik bygger du løsningslagene

1. I utviklingsmiljøet «basis» har du den grunnleggende løsningen med de vanlige uadministrerte tabellene og ingen andre tabeller. Eksporter deretter denne løsningen som administrert.
2. Du konfigurerer et nytt utviklingsmiljø for utvidelses- eller applaget som senere befinner seg oppå basislaget.
3. Du importerer det administrerte basislaget til utviklingsmiljøet for applag og oppretter en uadministrert løsning for applaget.
4. Du kan nå utvide datamodellen ved å legge til flere tabeller, kolonner, tabellrelasjoner, plugin-moduler, flyter og så videre, til den spesifikke «app»-løsningen. Deretter eksporterer du appløsningen som administrert. Legg merke til at appløsningen fortsatt avhenger av den grunnleggende lagløsningen, men det er en bedre tilnærming å administrere flere løsninger på denne måten. Vurder eksemplet nevnt før flyten som er avhengig av en egendefinert kolonne. I de fleste tilfeller ligger både den egendefinerte kolonnen og flyten i den samme appløsningen. Men selv om den egendefinerte kolonnen er en del av den grunnleggende løsningen, må du fullføre og distribuere den grunnleggende løsningen som administrert først, ellers kan ikke flyten i appløsningen opprettes.
5. I produksjonsmiljøet importerer du det administrerte basislaget og importerer deretter det administrerte applaget. Dette oppretter to administrerte lag i miljøet med klare avhengigheter mellom de administrerte løsningene.
6. Gjenta dette mønsteret for å ha så mange forskjellige løsninger som du trenger for å opprettholde. Vi anbefaler likevel at du holder antallet løsninger så lavt som mulig slik at løsningslag blir håndterbare.

Relaterte artikler

Bruk tabellsegmentering
Scenario 5: Støtte for teamutvikling