Pakattavien ulkoisten asiakassovellusten määrittäminen

Ulkoiset asiakassovellukset ovat erinomainen ratkaisu, kun niitä luodaan ja käytetään paikallisesti. Ne on kuitenkin suunniteltu hallitun pakkauksen kanssa. Pakattuja sovelluksia voidaan ottaa käyttöön muissa organisaatioissa. Määritä, haluatko pakata sovelluksesi vai pitää se paikallisena. OAuth-lisäosan sisältävät pakatut sovellukset voidaan ottaa käyttöön luodakseen omia yksilöllisiä OAuth-asetuksiaan tai ne voivat viitata sen organisaation asetuksiin, jossa sovellus kehitettiin.

Jos haluat työstää luonnosorganisaatioita, ota ensin Developer Hub (Dev Hub) käyttöön organisaatiossasi. Luonnosorganisaation määritystiedostossa määritetyt käyttöoikeudet tunnistetaan vain, jos ne on otettu käyttöön Dev Hub -organisaatiossa.

Tässä osiossa kuvataan, miten voit pakata, jakaa ja irrottaa ulkoisen asiakassovelluksen, joka sisältää OAuth-lisäosan. Määritämme tämän osion demoille ympäristön ottamalla ulkoisten asiakassovellusten käyttäjät ja käyttöoikeudet käyttöön kolmessa organisaatiossa. Jokaista käytetään eri ulkoisen asiakassovelluksen organisaation muodostamiseen.

• Organisaatio 1 on lähdeorganisaatio, johon globaali OAuth-asetustiedosto tallennetaan. Kaikki käyttöönotetut ulkoiset asiakassovellukset, joilla ei ole omaa globaalien asetusten tiedostoa, viittaavat tämän organisaation globaalien asetusten tiedostoon. Todellisessa skenaariossa tämän organisaation täytyy olla ei-ephemeral-organisaatio, joka pysyy aktiivisena, kunhan siihen liittyvät ulkoiset asiakassovellukset ovat käytössä. Tämän organisaation esimerkkikäyttäjänimi on johndoe@example.com.
• Organisaatio 2 sisältää organisaatiosta 1 käyttöönotetun ulkoisen asiakassovelluksen. Se viittaa organisaation 1 globaalin asetustiedostoon OAuth-tunnuksille. Tämän organisaation esimerkkikäyttäjänimi on johndoe@example2.com.
• Organisaatio 3 sisältää organisaatiosta 1 käyttöönotetun ulkoisen asiakassovelluksen, mutta se sisältää oman globaalin asetustiedoston, jolla on yksilölliset OAuth-tunnukset. Tämän organisaation esimerkkikäyttäjänimi on johndoe@example3.com.

Metadatan vieminen ja käyttöönotto uuteen organisaatioon

Vie metadata lähdeorganisaatiostasi ja ota se käyttöön toisessa organisaatiossa. Kun tämä prosessi on valmis, sekä lähdeorganisaatio (organisaatio 1) että uusi organisaatio (organisaatio 2) viittaavat lähdeorganisaation globaalien asetusten tiedostoon ja kuluttajan OAuth-tietoihin. Käytäntöjen tiedosto on valinnainen, kun se otetaan käyttöön toisessa organisaatiossa. Jos nykyistä käytäntötiedostoa ei ole määritetty yläpalkissa, käyttöönottoprosessi luo uuden käytäntötiedoston oletusarvoilla. Uusi organisaatio ei voi noutaa metadataa globaalista asetustiedostosta, koska lähdeorganisaatio omistaa sen ja uusi organisaatio voi vain viitata siihen.

Huomautus Jos poistat ulkoisen asiakassovelluksen lähdeorganisaatiosta, uuden organisaation ulkoinen asiakassovellus rikkoutuu. Koska uusi organisaatio vaatii globaalin asetustiedoston lähdeorganisaatiossa, tiedoston poistaminen aiheuttaa OAuth-kulun epäonnistumisen uudessa organisaatiossa.

• Datan noutaminen lähdeorganisaatiosta
  Hanki ulkoisen asiakassovelluksen metadataa lähdeorganisaatiosta käyttämällä noutotoimintoa.
• Ulkoisen asiakassovelluksen käyttöönotto, joka viittaa lähdeorganisaation globaaliin OAuth-asetusten tiedostoon
  Ota ulkoinen asiakassovellus käyttöön uudessa organisaatiossa ja pyydä sitä viittaamaan lähdeorganisaation tunnuksiin. Määritä tämä suhde muokkaamalla OAuth-asetustiedostossa olevaa OAuth-linkkiä ja poistamalla viite uuden organisaation package.xml-manifestitiedostossa olevaan globaaliin OAuth-asetustiedostoon.
• Ulkoisen asiakassovelluksen käyttöönotto uudella globaalilla OAuth-asetustiedostolla
  Ota lähdeorganisaation metadata käyttöön organisaatiossa sen omalla OAuth-kuluttajalla. Määritä sovellus poistamalla OAuth-asetustiedostosta OAuth-linkki ja lisää viite globaaliin OAuth-asetustiedostoon uuden organisaation package.xml-manifestitiedostossa.
• Ulkoisten asiakassovellusten liitäntä ja katkaisu
  Ulkoiset asiakassovellukset on suunniteltu toisen sukupolven (2GP) pakkauksille, mikä tarkoittaa, että ne on optimoitu luonnosorganisaatioiden lähdekoodiin perustuvaa kehitystä varten.