Den här artikeln innehåller information om de olika scenariona för hur du implementerar och utför felfri hantering av programlivscykeln (ALM) för anpassning av formulär i dina modellbaserade programlösningar.
I följande avsnitt beskrivs hur formulärkoppling fungerar och hur du upprätthåller anpassningar. De grundläggande utvecklingsscenariona med rekommendationer för hur du upprätthåller ett felfritt ALM för ett modellbaserat programformulär beskrivs utförligt i varje avsnitt som följer. Varje scenario innehåller steg som du följer och som kan hjälpa dig att implementera en korrekt ALM-process när du uppdaterar lösningen eller den modellbaserade programmet.
Skapa ett nytt formulär och underhålla det med flera hanterade lösningar
Följ stegen nedan om du vill implementera ett felfritt formulärs-ALM för det här scenariot.
Skapa ett nytt formulär med namnet FormA i utvecklingsmiljön och utför anpassningar i formuläret.
Skapa en ny lösning (med namnet Lösning A i diagrammet nedan) i utvecklingsmiljön, som blir en ohanterad lösning, och lägg till ditt nya formulär. Exportera den ohanterade lösningen. I det här steget exporteras ett fullständig FormXml för formuläret.
I testmiljön importerar du den hanterade lösningen från steg 2, vilket skapar FormA i testmiljön. I diagrammet nedan skapas FormA i testmiljön och i användargränssnittet för formuläret visas Fält1 och Fält2 som Lösning A har lagts till i formuläret.
När du sedan anpassar formuläret som du skapade i steg 1 med hjälp av en ny utvecklingsmiljö (källmiljö) importerar du den hanterade Lösning A som skapades i steg 2, kontrollera att utvecklingsinstansen du använder har FormA i ett hanterat läge. Som visas i diagrammet nedan importeras hanterad lösning A i utvecklingsmiljön och formuläret anpassas när aktiva anpassningar skapas. Sedan kan FormA läggas till i en ny ohanterad lösning (lösning B i diagrammet) och exporteras som en hanterad lösning från utvecklingsmiljön. I det här steget exporteras ett differentiellt (diff) FormXml för formuläret.
Importera hanterad lösning (Lösning B) från steg 4 i testmiljön. Som visas i diagrammet nedan lägger lösning B till ett nytt fält3 i FormA och tar bort fält2, som har lagts till av lösning A. Användargränssnittet för formuläret i testmiljön visar nu fält3 och Fält1 i formuläret men inte Fält2 efter kopplingen.
Ett exempel som inte är felfritt för det här scenariot
Som framgår av diagrammet nedan är det ingen bra metod att skapa flera hanterade lösningar från utvecklingsmiljön där grundlösningen (Lösning A) är i ohanterat tillstånd. Det här beror på att när du skapar en annan ohanterad lösning (Lösning B) för det ohanterade formuläret exporteras FormXml som en fullständig FormXml, i stället för en FormXml-fil (se det giltiga scenariot ovan). Ändringar som att ta bort en kolumn påverkas inte längre.
Skapa ett nytt formulär och göra anpassningar med hjälp av korrigeringar och uppgraderingar
Följ stegen nedan om du vill implementera ett felfritt formulärs-ALM för det här scenariot.
Skapa ett nytt formulär med namnet FormA i utvecklingsmiljön och utför anpassningar i formuläret.
Skapa en ny lösning (Lösning A i diagrammet nedan), som blir en ohanterad lösning, och lägg till ditt nya formulär. Exportera den ohanterade lösningen. I det här steget exporteras ett fullständig FormXml för formuläret.
I testmiljön importerar du den hanterade lösningen från steg 2, som skapar formuläret i testmiljön. I diagrammet nedan skapas FormA i testmiljön och i användargränssnittet för formuläret visas Fält1 och Fält2 som Lösning A har lagts till i formuläret.
När du sedan anpassar formuläret som du skapade i steg 1 med hjälp av snabbkorrigeringar, använder du samma miljö där lösning A är i ohanterat tillstånd och skapar en korrigering för lösningen och anpassar formuläret. Nu ska du exportera korrigeringen som en hanterad lösning. I det här steget exporteras ett fullständig formXml för formuläret.
Importera den hanterade lösningen med korrigering från steg 4 i testmiljön. Som visas i diagrammet nedan lägger korrigeringen Solution A till ett nytt fält3 i FormA och tar bort Fält2, som har lagts till av Lösning A.
Anteckning
Korrigeringar som innehåller fullständig formXml jämförs alltid med basskiktet som patchen skapades från och ignorerar eventuella mellanliggande korrigeringar mellan basen och den aktuella korrigeringen. Som ett resultat tas Field2 bort eftersom det finns i grundlager Lösning A och borttagningen identifieras. Å andra sidan läggs Field3 till av denna korrigeringslösning och kan inte tas bort av efterföljande korrigeringar. Fält som läggs till via programkorrigeringslösningar är additiva till sin typ.
När du ytterligare anpassar formuläret du skapade i steg 1 med hjälp av uppgraderingar, använd samma miljö där lösning A befinner sig i ett ohanterat tillstånd och klon lösning A för att skapa uppgraderingslösningen och anpassa formuläret. Exportera sedan lösning A uppgraderingen som en hanterad lösning. I det här steget exporteras ett fullständig FormXml för formuläret.
Importera den hanterade lösning A- uppgraderingen från steg 6 i din testmiljö. Som visas i diagrammet nedan lägger lösning A uppgraderingen till ett nytt Fält4 i FormA och tar bort Fält2, som har lagts till av lösning A. Användargränssnittet för formuläret i testmiljön visar nu Fält1, Fält3 och Fält4 i formuläret men Fält2 tas bort efter formuläret har kopplats från importen.
Anpassa ett befintligt hanterat formulär och underhålla det med hjälp av flera hanterade lösningar
Följ stegen nedan om du vill implementera ett felfritt formulärs-ALM för det här scenariot.
Redigera ett befintligt hanterat formulär, med namnet FormB i detta exempel, i din utvecklingsmiljö och utför anpassningar på formuläret. Observera att lösning A är den hanterade lösningen som redan har installerats för formuläret i utvecklingsmiljön.
Skapa en ny lösning ( lösning B i nedanstående diagram), som är en icke-hanterad lösning, och lägg till FormB. Exportera den ohanterade lösningen. I det här steget exporteras ett differentiellt (diff) FormXml för formuläret.
Importera den hanterade lösningen från steg 2 i din testmiljö och skapa ett andra lösningsskikt för formuläret. I nedanstående diagram får FormB de sammanslagna ändringarna från Lösning A och Lösning Bi testmiljön och UI för formuläret visar Fält1 och Fält3 på formuläret men inte Fält2, som togs bort av Lösning B.
När du sedan anpassar formuläret du anpassade i steg 1 med hjälp av nya hanterade lösningar bör du se till att använda en ny utvecklingsmiljö som har FormB i hanterad status. Som visas i diagrammet nedan importeras hanterade lösningar för Lösning A och Lösning B i den nya utvecklingsmiljön. FormB är anpassat och skapar aktiva anpassningar, som sedan kan läggas till i en ny lösning (lösning C i diagrammet) och exporteras som en hanterad lösning.
Importera den hanterade lösningen C från steg 4 i din testmiljö. Som visas i diagrammet nedan lägger lösning C till ett nytt Fält4 i FormB och tar bort Fält3, som har lagts till av lösning B. Användargränssnittet för formuläret i testmiljön visar nu Fält1 och Fält4 i formuläret men inte Fält2 och Fält3.
Ett exempel som inte är felfritt för det här scenariot
Som visas i nedanstående diagram är det inte en sund ALM-praxis att skapa flera hanterade lösningar från utvecklingsmiljön som innehåller en annan ohanterad lösning som du skapade för samma form. Lägg märke till att lösning B är i obestyrd skick. När du skapar en annan ohanterad lösning ( Lösning C) för FormB exporteras FormXml som en diff FormXml som visas i steg 4 i ovanstående scenario. Men FormB innehåller också ändringarna från lösning B, som skrivs över av dina nya ändringar.
Som visas i diagrammet nedan läggs Fält3 till i FormB i lösningB. Men nu när du skapar en ny lösning C i den här miljön, med lösning B i ohanterat tillstånd och tar bort Fält3, tas även Fält3 bort i utvecklingsmiljön. Field3 kommer inte att spåras i diff FormXml när lösningen exporteras, eftersom ändringen att lägga till och ta bort den här kolumnen gjordes i samma aktiva lager. Det betyder att när hanterad lösning Cimporteras i testmiljön kommer formuläret fortfarande att göra Field3 eftersom diff FormXml aldrig registrerar det som borttaget (som om det togs bort i steg 5 i ALM-scenariot för sund form ovan). Genom att utföra dina formuläranpassningar på detta sätt kommer utvecklingsmiljön att vara oförenlig med testmiljön.
Anpassa ett befintligt hanterat formulär och underhålla det med korrigeringar och uppgraderingar
Följ stegen nedan om du vill implementera ett felfritt formulärs-ALM för det här scenariot.
Anpassa ett befintligt hanterat formulär, med namnet FormB i det här exemplet, i din utvecklingsmiljö och utför anpassningar på formuläret. Observera att lösning A är den hanterade lösningen som redan har installerats för formuläret i utvecklingsmiljön.
Skapa en lösning ( Lösning B), som kommer att vara en icke-hanterad lösning och lägg till FormB. Exportera den ohanterade lösningen. Detta steg exporterar en diff FormXml för formuläret.
I din testmiljö importerar du hanterad lösning B från steg 2 och skapar därmed ett andra lösningsskikt för formuläret. I nedanstående diagram får FormB de sammanslagna ändringarna från lösning A och lösning B i testmiljön. Dessutom visar användargränssnittet för FormBField1 och Field3 på formuläret men inte Field2, som togs bort av lösning B.
När du ytterligare anpassar formuläret som du anpassade i steg 1 med en korrigeringslösning kan du använda samma utvecklingsmiljö som steg 1 där lösning B finns i ett obehandlat tillstånd. Som visas i diagrammet nedan är Lösning A i ett hanterat tillstånd och Lösning B är i ett ohanterat tillstånd. Formuläret anpassas ytterligare och du skapar en korrigeringsfil för lösning B som lägger till formuläret till den här lösningen och exporterar den som en hanterad patchlösning. Detta steg exporterar en diff FormXml.
I din testmiljö importerar du hanterad korrigeringslösning B från steg 4. Som visas i nedanstående diagram lägger lösning B Patch till ett nytt fält 4 i FormB och tar bort fält 3, som har lagts till av lösning B.
Anteckning
Patcher är additiva till sin natur och kan inte ta bort komponenter, såsom kolumner, från formuläret. Så, Field3 kommer inte att tas bort från formuläret. UI för formuläret i testmiljön visar nu Fält1, Fält3 och Fält4 på formuläret, men inte Fält2.
När du ytterligare anpassar formuläret du skapade i steg 1 med hjälp av uppgraderingar, använd samma miljö där lösning B befinner sig i ett ohanterat tillstånd och klon lösning B för att skapa uppgraderingslösningen och anpassa FormB. Exportera uppgraderingen som en hanterad lösning. Detta steg exporterar en diff FormXml för formuläret.
Importera hanterad lösning B med uppgraderad lösning från steg 6 i testmiljön. Som visas i diagrammet nedan lägger lösning B uppgradering till ett nytt Fält5 i FormB och tar bort Fält3, som har lagts till av lösning B. Användargränssnittet för formuläret i testmiljön visar nu Fält1 och Fält4 och Fält5 i formuläret men Fält2 och Fält3 har tagits bort.
Underhålla ohanterade lösningar och anpassningar för en ny form i flera utvecklingsmiljöer
Följ stegen nedan om du vill implementera ett felfritt formulärs-ALM för det här scenariot.
I utvecklingsmiljö 1 skapar du en ny FormA och utför anpassningar på formuläret.
Skapa en lösning ( Lösning A i nedanstående diagram), som kommer att vara en icke-hanterad lösning, och lägg till ditt nya formulär. Exportera lösningen som ohanterad. I det här steget exporteras ett fullständig FormXml för formuläret.
I utvecklingsmiljö 2 importerar du den ohanterade lösningen från steg 2, vilket skapar formuläret i utvecklingsmiljö 2. I nedanstående diagram skapas FormA och användargränssnittet för formuläret visar fält 1 och fält 2 som lösning A har lagts till i formuläret.
Du anpassar vidare formuläret i utvecklingsmiljö 2 och gör aktiva anpassningar i miljön, till exempel att lägga till en ny kolumn med namnet Field3. FormA visar nu Fält1, Fält2 och Fält3.
I din utvecklingsmiljö 1 anpassar du formuläret ytterligare genom att lägga till Field4. Användargränssnittet för formuläret i utvecklingsmiljön 1 visar nu fält 1, fält 2 och fält 4.
Exportera ohanterad lösning A med ändringarna i steg 5. I det här steget exporteras ett fullständig FormXml för formuläret.
I Utvecklingsmiljö 2 importerar du ohanterad lösning A uppgraderad från steg 6. Eftersom lösningen du importerar innehåller hela FormXml för FormA skriver den över den aktiva anpassningen som gjorts i utvecklingsmiljö 1. Så, formuläret visar nu bara Fält1, Fält2 och Fält4, men inte Fält3, vilket var den ytterligare aktiva anpassningen som gjordes i utvecklingsmiljö 1. Det här beteendet inträffar vid alla ohanterade lösningsimportar som har hela FormXml för formuläret.
Underhålla ohanterade lösningar och anpassningar för en befintlig form i flera utvecklingsmiljöer
Följ stegen nedan om du vill implementera ett felfritt formulärs-ALM för det här scenariot.
I utvecklingsmiljö 1 anpassar du ett befintligt formulär med namnet FormB i det här exemplet. Utför sedan anpassningar på formuläret.
Skapa en lösning ( Lösning B i nedanstående diagram), som kommer att vara en icke-hanterad lösning, och lägg till FormB. Exportera lösningen som ohanterad. Detta steg exporterar en diff FormXml för formuläret.
I utvecklingsmiljö 2 importerar du den ohanterade lösningen från steg 2 och skapar därmed ett andra lösningsskikt för formuläret. FormB UI visar Fält1, Fält2 och Fält3 efter att formuläret har sammanfogats.
Du anpassar vidare formuläret i utvecklingsmiljö 2 och gör aktiva anpassningar i miljön, till exempel att lägga till en ny kolumn med namnet Field4. FormB visar nu Fält1, Fält2, Fält3 och Fält4.
I utvecklingsmiljö 1 anpassar du formuläret ytterligare och lägger till en ny kolumn med namnet Field5. Användargränssnittet för formuläret i utvecklingsmiljö 1 visar nu fält 3 och fält 5.
Exportera ohanterad lösning B med ändringarna i steg 5. Detta steg exporterar en diff FormXml för formuläret.
I Utvecklingsmiljö 2 importerar du ohanterad lösning B uppgraderad från steg 6. Eftersom lösningen du importerar innehåller diff FormXml för FormB kommer den att gå samman med den aktiva anpassningen som gjorts i utvecklingsmiljö 1. Så nu visar formuläret Fält1, Fält2, Fält3, Fält4 och Fält5. Det här beteendet inträffar för alla ohanterade lösningsimportar som har diff FormXml för formuläret.
Om formulärets sammanslagning i steg 7 inte är vad du vill ha trots att du importerar en diff FormXml med den ohanterade lösningen och du vill kunna skriva över de aktiva anpassningarna som gjorts i utvecklingsmiljö 2, ta sedan bort det aktiva lagret för FormB. Mer information: Ta bort ett ohanterat lager.
Exportera ohanterad lösning B med ändringarna i steg 5. Detta steg exporterar en diff FormXml för formuläret.
I Utvecklingsmiljö 2 importerar du ohanterad lösning B uppgraderad från steg 9. Eftersom det inte finns något aktivt lager för formuläret i utvecklingsmiljö 2 (se steg 8) importeras alla ändringar från ohanterad lösning B trots att du importerar diff FormXml för FormB. Så, formuläret visar nu bara Fält1, Fält2, Fält3 och Fält5. Det här beteendet inträffar för alla ohanterade lösningsimportar som har diff FormXml för formuläret. Detta är samma resultat som steg 7 i underhållet av obehandlade lösningar och anpassningar för en befintlig form i flera utvecklingsmiljöer.
Fullständig och differentiell XML-form
Varje exporterat lösningspaket innehåller en anpassningar.xml-fil. När ett formulär ingår i en lösning finns den relaterade formulärdefinitionen inom FormXml-sektionerna i filen customizations.xml. FormXml kan antingen vara full eller differentiell (diff).
Full FormXml
FormXml du får när du exporterar en lösning för ett formulär i obestämt tillstånd kallas en fullständig FormXml. Fullt betyder att den innehåller hela formdefinitionen. När du skapar ett nytt formulär och exporterar det, kommer formuläret alltid att vara ett fullständigt FormXml eftersom formuläret i den miljö du exporterar från är i ett ohanterat tillstånd och också i ett skapat tillstånd. Om du exporterar ytterligare lösningar från samma miljö kommer de också att innehålla en fullständig FormXml. Eftersom detsolutionaction attribut anger en diff FormXml, hela FormXml i filen customization.xml i den lösning du exporterar innehåller intesolutionaction attribut.
Differential (diff) FormXml
FormXml du får när du exporterar en lösning för ett formulär i ett hanterat tillstånd kallas en differentiell eller diff FormXml. Diff betyder att FormXml endast innehåller de ändringar som gjorts i de aktiva anpassningarna i den miljön och inte hela formulärdefinitionen. När du anpassar ett befintligt hanterat formulär och exporterar det, kommer formuläret alltid att vara ett annorlunda FormXml eftersom det bara innehåller de aktiva ändringarna som görs i det. Skillnaden FormXml i filen customization.xml i den lösning du exporterar innehållersolutionaction attribut som definierar vad ändringarna är, som tillagt, borttaget, modifierat.
Diff FormXml ser till att din lösning bara kommer att uttrycka de ändringar som ditt program behöver och kommer att påverkas mindre av ändringar från andra lager. Diff FormXml gör också lösningen mindre skrymmande och hjälper den att importera snabbare.
Demonstrate the use of Microsoft Power Platform solutions to simplify, automate, and empower business processes for organizations in the role of a Functional Consultant.