Ratkaisun päivityksiä yksinkertaistavien korjaustiedostojen luominen
Jos lisäät entiteetin ratkaisuun ja viet ratkaisun, ratkaisu ja kaikki siihen liittyvä omaisuus viedään siinä ratkaisussa. Nämä resurssit sisältävät määritteitä, lomakkeita, näkymiä, suhteita ja visualisointeja sekä muita entiteettiin pakattuja resursseja. Kaikkien objektien vieminen tarkoittaa sitä, että voit vahingossa muokata objekteja kohdeympäristössä tai siirtää tahattomia riippuvuuksia.
Tämän ongelman ratkaisemiseksi voit luoda ja julkaista ratkaisun korjaustiedostoja, jotka sisältävät entiteettien alikomponentteja sen sijaan, että julkaistaisiin koko entiteetti ja kaikki sen resurssit. Alkuperäinen ratkaisu ja yksi tai useampi asiaan liittyvä korjaus voidaan koota (yhdistää) myöhemmin ratkaisun päivitettyyn versioon, joka voi korvata alkuperäisen ratkaisun Microsoft Dataverse -kohdeorganisaatiossa.
Korjaukset
Voit käyttää korjaustiedostoja joko hallittuihin tai hallitsemattomiin ratkaisuihin ja lisätä vain entiteettien ja niihin liittyvien entiteettisuhteiden muutoksia. Korjaustiedostoissa ei ole mukautettuja järjestelmäosia tai suhteita, joista ne ovat riippuvaisia, koska nämä osat on jo otettu käyttöön organisaatiossa. Kehitysjakson jossakin vaiheessa voit koota kaikki korjaustiedostot uuteen ratkaisuversioon ja korvata alkuperäisen ratkaisun, josta korjaustiedostot on luotu.
Korjaustiedostot tallennetaan Dataverse -tietokantaan Solution
-entiteettitietueina. ParentSolutionId
-määrite, joka ei ole null, osoittaa, että ratkaisu on korjaus. Korjaustiedostoja voidaan luoda ja hallita .NETin SDK:n tai verkko-ohjelmointirajapintojen kautta, mikä on kätevää hyötyä automaation kehittämisessä, kuten tuotteen asennuskomentosarjassa. Dataversen WWW-sovelluksessa on kuitenkin erilaisia www-lomakkeita, joiden avulla voit luoda ja hallita korjaustiedostoja vuorovaikutteisesti.
Korjaustiedostoja voi luoda vain pääratkaisusta CloneAsPatchRequest- tai CloneAsPatch-toiminnolla.
Korjaustiedoston ylätaso ei voi olla korjaustiedosto.
Korjaustiedostoilla voi olla vain yksi pääratkaisu.
Korjaustiedosto luo riippuvuussuhteen (ratkaisutasolla) riippuvuuden pääratkaisulle.
Voit asentaa korjaustiedoston vain, jos pääratkaisu on olemassa.
Korjaustiedostoa ei voi asentaa, ellei pääratkaisun yksilöivä nimi ja pää- tai aliversion numero, sellaisena kuin se on määritetty
ParentSolutionId
-tunnuksessa, ole sama kuin kohdeorganisaatioon asennetun pääratkaisun nimi.Korjausversiolla on oltava sama pää- ja alinumero, mutta suurempi koontiversio- ja julkaisunumero kuin pääratkaisun versionumero. Näyttönimi voi olla toinen.
Jos ratkaisussa on korjaustiedostoja, seuraavien korjaustiedostojen versionumeron on oltava numeerisesti suurempi kuin mikään kyseisen ratkaisun aiemmin asennettu korjaustiedosto.
Korjaustiedostot tukevat samoja toimintoja kuin ratkaisut, kuten lisäpäivitystä, mutta ei poistoa. Osia ei voi poistaa ratkaisusta käyttämällä korjaustiedostoa. Jos haluat poistaa osia ratkaisusta, tee päivitys.
Hallittuina viedyt korjaustiedostot on tuotava hallitun ylätason ratkaisun päälle. Sääntö on se, että korjaussuojauksen (hallittu tai hallitsematon) on vastattava sen päätasoa.
Älä käytä ei-hallittuja korjaustiedostoja tuotantoympäristöissä.
Korjaustiedostoja tuetaan vain Dataverse -organisaatioissa, joiden versio on 8.0 tai uudempi.
Tämän version tukiratkaisun korjaustiedostojen SolutionPackager- ja PackageDeployer-työkalut. Lisätietoja korjaustiedostoja koskevista komentorivivalitsimista on työkalun käytönaikaisessa ohjeessa.
Luo korjaustiedosto
Voit luoda korjaustiedoston organisaation hallitsemattomasta ratkaisusta käyttämällä CloneAsPatchRequest-sanomaa tai CloneAsPatch-toimntoa taikka verkkosovellusta. Kun korjaustiedosto on luotu, alkuperäinen ratkaisu lukitaan. Sitä ei voi silloin muuttaa eikä viedä niin kauan kuin organisaatiossa on riippuvaisia korjaustiedostoja, jotka tunnistavat ratkaisun pääratkaisuksi. Korjaustiedostojen versiointi on samankaltainen kuin ratkaisun versiointi, ja se on määritetty seuraavassa muodossa: major.minor.build.release. Muutoksia ei voi tehdä aiemmin luotuihin pää- tai aliratkaisuversioihin korjaustiedostoa luotaessa.
Ratkaisun vieminen ja tuominen
Korjaustiedoston voi viedä ja tuoda käyttämällä .NETin SDK:ta tai verkko-ohjelmointirajapintoja, verkkosovellusta taikka Package Deployer -työkalua. Soveltuvat .NETin SDK:n pyyntöluokat ovat ImportSolutionRequest ja ExportSolutionRequest. Verkko-ohjelmointirajapintaan liittyvät toiminnot ovat ImportSolution-toiminto ja ExportSolution-toiminto.
Korjausesimerkkejä
Seuraavassa taulukossa on luettelo korjausesimerkin tiedoista. Huomaa, että tässä esimerkissä ratkaisu ja korjaukset tuodaan numerojärjestyksessä ja ne ovat lisäaineita, mikä on yhdenmukainen ratkaisun tuonnin kanssa yleensä.
Korjauksen nimi | Kuvaus |
---|---|
SolutionA, versio 1.0 (hallitsematon) | Sisältää entityA:n, jossa on 6 kenttää. |
SolutionA, versio 1.0.1.0 (hallitsematon) | Sisältää entityA:n, jossa on 6 kenttää (3 päivitetty), ja lisää entityB:n, jossa on 10 kenttää. |
SolutionA, versio 1.0.2.0 (hallitsematon) | Sisältää entityC:n, jossa on 10 kenttää. |
Tuontiprosessi on seuraava.
Kehittäjä tai mukauttaja tuo ensin perusratkaisun (SolutionA 1.0) organisaatioon. Tuloksena on entityA, jonka organisaatiossa on kuusi kenttää.
Seuraavaksi tuodaan SolutionA-korjaus 1.0.1.0. Organisaatiossa on nyt entityA, jossa on 6 kenttää (3 on päivitetty), sekä entityB, jossa on 10 kenttää.
Lopuksi tuodaan SolutionA-korjaus 1.0.2.0. Organisaatiossa on nyt entityA, jossa on 6 kenttää (3 on päivitetty), sekä entityB, jossa on 10 kenttää ja entityC, jossa on 10 kenttää.
Toinen korjausesimerkki
Tarkastellaan toista korjausesimerkkiä ja seuraavassa taulukossa lueteltuja tietoja.
Korjauksen nimi | Kuvaus |
---|---|
SolutionA, versio 1.0 (hallitsematon, perusratkaisu) | Sisältää Account -entiteetin, jossa tilinumerokentän pituutta muutetaan 20:stä 30:een merkkiin. |
SolutionB, versio 2.0 (hallitsematon, eri toimittaja) | Sisältää Account -entiteetin, jossa tilinumerokentän pituutta muutetaan 50:een merkkiin. |
SolutionA, versio 1.0.1.0 (hallitsematon, korjaustiedosto) | Sisältää päivityksen Account -entiteettiin, jossa tilinumerokentän pituutta muutetaan 35:een merkkiin. |
Tuontiprosessi on seuraava:
Kehittäjä tai mukauttaja tuo ensin perusratkaisun (SolutionA 1.0) organisaatioon. Tuloksena on
Account
-entiteetti, jolla on 30 merkin pituinen tilinumerokenttä.SolutionB tuodaan. Organisaatiossa on nyt
Account
-entiteetti, jolla on 50 merkin pituinen tilinumerokenttä.SolutionA-korjaus 1.0.1.0 tuodaan. Organisaatiossa on yhä
Account
-entiteetti, jolla on 50 merkin pituinen tilinumerokenttä, kuten sovellettu SolutionB:ssä.SolutionB:n asennus on poistettu. Organisaatiossa on nyt
Account
-entiteetti, jolla on 35 merkin pituinen tilinumerokenttä, kuten sovellettu SolutionA:n korjaustiedostossa 1.0.1.0.
Korjauksen poistaminen
Voit poistaa korjaustiedoston tai perusratkaisun (päätason) käyttämällä DeleteRequest -toimintoa tai HTTP DELETE
-metodia www-ohjelmointirajapinnalle. Poistoprosessi eroaa hallitussa tai hallitsemattomassa ratkaisussa, jossa on vähintään yksi järjestelmässä oleva korjaus.
Jos kyseessä on hallitsematon ratkaisu, kaikkien korjaustiedostojen asennus on poistettava perusratkaisusta ensin käänteisessä versiossa, joka on luotu, ennen perusratkaisun poistamista.
Hallitun ratkaisun kohdalla poistat yksinkertaisesti perusratkaisun. Dataverse -järjestelmä poistaa korjaustiedostot automaattisesti käänteisessä versiotilauksessa ennen perusratkaisun asennuksen poistamista. Voit myös poistaa yksittäisen korjaustiedoston asennuksen.
Ratkaisun päivittäminen
Ratkaisun päivittäminen tarkoittaa sitä, että kaikki ratkaisun korjaukset (yhdistettävään) otetaan ratkaisun uuteen versioon. Tämän jälkeen ratkaisun lukitus poistuu, ja sitä voi muokata uudelleen (vain hallitsematon ratkaisu) tai viedä. Jos kyseessä on hallittu ratkaisu, ratkaisun muita muokkauksia ei sallita, paitsi kun luodaan korjaustiedostoja vastapäivitetystä ratkaisusta. Jos haluat määrittää korjaustiedostoja hallitsemattomaksi ratkaisuksi, käytä CloneAsSolutionRequest- tai CloneAsSolution-toimintoa. Ratkaisun kloonaus luo hallitsemattomasta ratkaisusta uuden version, joka sisältää kaikki sen korjaustiedostot ja suuremman major.minor-versionnumeron, saman yksilöivän nimen ja näyttönimen.
Hallitun ratkaisun asioita käsitellään hieman eri tavalla. Ensin kloonaat hallitsemattoman ratkaisun (A), joka sisältää kaikki sen korjaustiedostot, ja viet sen sitten hallittuun ratkaisuun (B). Kohdeorganisaatiossa, joka sisältää ratkaisun (A) ja sen korjaustiedostojen hallitun version, tuodaan hallittu ratkaisu (B) ja suoritetaan DeleteAndPromoteRequest- tai DeleteAndPromote-toiminto. Näin korvataan hallittu ratkaisu (A) ja sen korjaustiedostot päivitetyllä hallitulla ratkaisulla (B), jossa on suurempi versionumero.