Viimeksi päivitetty 19. huhtikuuta 2024
Jotta voimme valmistautua organisaatiosi jatkuvaan kasvuun, meidän täytyy silloin tällöin suorittaa instanssin päivitykseksi kutsuttu toimenpide, jolloin päivitämme instanssiasi tukevan infrastruktuurin datakeskuksissamme. Huoltotoimen jälkeen instanssisi siirretään uuteen datakeskukseen ja instanssisi nimi muuttuu. Näin voimme jatkossakin tarjota organisaatioille samantasoista suorituskykyä, jota ne ovat tottuneet saamaan Salesforcelta.
Jos noudatat suosittelemiamme käytäntöjä, tämän huoltotoimen tulisi tapahtua saumattomasti. Alla on joitakin yleisimpiä instanssien päivitykseen liittyviä kysymyksiä.
HUOMAA: Tämä asiakirja on tarkoitettu vain tiedotustarkoituksiin eikä se ole osa lainvoimaista tai muulla tavoin sitovaa sopimusta. Salesforce voi muuttaa tässä asiakirjassa kuvattuja menettelytapoja ja käytäntöjä oman harkintansa mukaan.
Yleisimmät kysymykset
1. Mikä on instanssin päivitys ja miten se hyödyttää minua?
Jotta voimme valmistautua organisaatiosi jatkuvaan kasvuun, meidän täytyy silloin tällöin suorittaa instanssin päivitykseksi kutsuttu toimenpide, jolloin päivitämme instanssiasi tukevan infrastruktuurin datakeskuksissamme. Tämän huoltotoimen jälkeen instanssisi siirretään uuteen datakeskukseen ja instanssisi nimi muuttuu. Näin voimme jatkossakin tarjota organisaatioille samantasoista suorituskykyä, jota ne ovat tottuneet saamaan Salesforcelta.
2. Mitä minun täytyy tehdä valmistautuakseni instanssin päivitykseen?
Tutustu alla kuvattuihin suositeltuihin käytäntöihimme varmistaaksesi, että olet valmistautunut tähän huoltotoimeen. Jos et noudata suosittelemiamme käytäntöjä, loppukäyttäjäsi eivät välttämättä voi käyttää Salesforcea huollon jälkeen.
Suositeltuihin käytäntöihin sisältyy:
i. Oman toimialueen käyttöönotto
ii. Kovakoodattujen viitteiden päivittäminen ei-instanssikohtaisiksi viitteiksi
iii. Salesforcen kaikkien IP-osoitteiden käytön salliminen
iv. Toimenpiteidesi suunnitteleminen huoltojaksojen mukaisesti
Sinun täytyy ehkä suorittaa seuraavat toimenpiteet välttyäksesi odottamattomilta palvelukatkoksilta:
i. Jos sinulla on kovakoodattuja viitteitä (esimerkiksi na1.salesforce.com), muista päivittää ne suhteellisiksi, ei-instanssikohtaisiksi URL-osoitteiksi (esimerkiksi login.salesforce.com).
ii. Jos sinä tai tiimisi olette määrittäneet yrityksenne verkkoasetukset tai sähköpostisuodattimet rajoittamaan käytön vain tiettyihin IP-osoitealueisiin tai datakeskuksiin, muista lisätä uusimmat osoitealueemme. Lisätietoja sisällytettävistä IP-osoitealueista löytyy artikkelista Salesforcen sallittavat IP-osoitteet.
iii. Ota Oma toimialue käyttöön ennen huoltoa.
iv. Valmistaudu päivittämään integraatiosi, jos niissä esiintyy ongelmia huollon jälkeen.
v. Valmistaudu tyhjentämään DNS-välimuistisi, jos ”Huolto on käynnissä” -hälytys ei katoa sisäänkirjautumissivulta huollon jälkeen.
vi. Jos tallennat sertifikaatteja paikalliseen välimuistiin, liity Trailblazer Community -yhteisön Certificate Changes -ryhmään saadaksesi uusimmat sertifikaatit.
3. Onko Vain luku -tila käytettävissä instanssin päivityksen aikana?
Kyllä, Vain luku -tila on käytettävissä huollon aikana. Lisätietoja Vain luku -käyttöoikeuksista on Vain luku -tilan yhteenveto -artikkelissa.
4. Vaikuttaako instanssin päivitys Salesforce for Outlookin (SFO) OAuth-valtuuksiin?
a. Instanssin päivityksen jälkeen kaikki käyttäjät kirjataan automaattisesti ulos SFO:sta ja heitä pyydetään kirjautumaan takaisin sisään ohjatun määritystoiminnon kautta.
b. Jos SFO:hon sisäänkirjautumisessa ilmenee ongelmia huollon jälkeen, noudata Salesforce for Outlook OAuth reauthentication -artikkelissa kuvattuja ohjeita.
c. Jos sinulla on kysyttävää SFO:sta, lähetä viesti Trailblazer Communityn Salesforce for Outlook & Email Connect -ryhmään.
5. Jos aion tarkastella sähköpostilokejani instanssin päivityksen jälkeen, täytyykö minun pyytää niitä ennen huoltojaksoa?.
a. Ei. Sähköpostilokeja säilytetään keskitetysti ja ne ovat saatavilla instanssin päivityksen jälkeen, joten sinun ei tarvitse pyytää niitä ennen huoltojaksoa, sijainnin vaihtoa, instanssin päivitystä tai organisaation siirtoa.
6. Vaikuttaako instanssin päivitys sandboxien päivityksiini?
a. Sandboxien päivitysjono keskeytetään 4 tuntia ennen instanssin päivityksen alkua.
b. Jos organisaatiollasi oli sandboxin päivitys kesken, kun jono keskeytettiin, sandoxin päivitys pysäytetään. Sandboxisi päivitys käynnistyy uudelleen (alusta) 24 tuntia instanssin päivityksen jälkeen.
7. Täytyykö minun käynnistää integraatiot uudelleen huollon jälkeen?
a. Integraatioiden uudelleenkäynnistys ei ole tarpeen, mutta jos niissä esiintyy ongelmien instanssin päivityksen jälkeen, suosittelemme käynnistämään ne uudelleen vianmäärityksen ensimmäisenä ratkaisuvaihtoehtona.
b. Käynnistämällä integraatiosi uudelleen huoltojakson jälkeen tyhjennät DNS-hakujen välimuistin, mikä sallii integraatioidesi havaita uuden tietokeskuksen IP-osoitteen.
c. Jokaisella integraatiolla voi olla erilaiset toimenpiteet integraation käynnistämiseksi uudelleen. Suosittelemme pyytämään tarkat toimenpiteet integraation kehittäjältä. Monet AppExchangessa tarjolla olevat integraatiot sisältävät myös ohjeet sisäänkirjautumiseksi/uudelleenkäynnistämiseksi.
8. Käytetäänkö uudessa instanssissa sertifikaatteja, joita käytetään tämänhetkisessä instanssissani [INSTANSSI].salesforce.com ja [INSTANSSI]-api.salesforce.com?
9. Käytetäänkö uudessa instanssissa samoja välisertifikaatteja, juurisertifikaatteja ja lähteviä asiakkaalta–Salesforcelle-sertifikaatteja?
Kyllä, väli- ja juurisertifikaatit säilyvät ennallaan. Lisäksi lähtevät sertifikaatit, joita käytetään SAML:lle, SSO:lle ja APEX:ille, eivät muutu.
10. Vaikuttaako instanssin päivitys Sähköpostista tapaukseksi- tai Sähköpostista Apexiin -toimintojen reititysosoitteisiin?
a. Ei. Instanssin päivitys ei vaikuta Sähköpostista tapaukseksi- tai Sähköpostista Apexiin -toimintojen reititysosoitteisiin.
b. Olemassa oleviin sähköpostiosoitteisiin lähetetyt sähköpostit toimitetaan päivityksen jälkeen ilman, että osoitteita tarvitsisi muuttaa.
11. Viivästyvätkö palveluosoitteisiin lähetetyt sähköpostit (Sähköpostista tapaukseksi, Sähköpostista Apexiin, Sähköposti Salesforceen, reply2chatter, jne...) instanssin päivityksen jälkeen?
Jotkin sähköpostit viivästyvät. Sovelluspalvelimet eivät ole käytettävissä ja sähköpostit pysyvät Salesforcen sähköpostipalvelimilla instanssin päivityksen aikana.
Kun uusi instanssi on aktivoitu, uudet sähköpostit toimitetaan välittömästi ja jonossa olevat sähköpostit toimitetaan seuraavalla uudelleenyrityskerralla. Aika, jolloin instanssi ei ole käytettävissä, vaikuttaa siihen, milloin jonossa olevia viestejä yritetään uudelleen.
12. Säilyvätkö uuden instanssini huoltojaksot samoina kuin edellisellä instanssillani päivityksen jälkeen?
Kyllä.
13. Onko uudella instanssillani sama järjestelmän standardihuoltojakso kuin edellisellä instanssillani päivityksen jälkeen?
Kyllä.
14. Muuttuuko organisaationi tunnus instanssin päivityksen jälkeen?
Ei.
15. Voinko kieltäytyä instanssin päivityksestä?
Et. Kaikki instanssin päivitykseen kuuluvat organisaatiot siirretään.
16. Mitä tapahtuu ”vanhassa datakeskuksessa olevalle datalle instanssin päivityksen jälkeen?
Kun instanssin päivitys on suoritettu onnistuneesti, poistamme käytöstä laitteiston, joka isännöi instanssiasi vanhassa datakeskuksessa. Käyttämämme toimenpiteet varmistavat, ettei datasi poistu edellisestä datakeskuksesta ja että se täyttää kaikki vaatimustenmukaisuus- ja tietoturvavaatimukset. Luottamuksesi ylläpitäminen on tärkein päämäärämme.
17. Vaikuttaako instanssin päivitys käyttämiimme kolmansien osapuolten sisällönjakeluverkkoihin (CDN)?
Kyllä. Sinun täytyy suorittaa seuraavat toimenpiteet, jos käytät kolmannen osapuolen CDN-verkkoa:
a. Jos käytät kiihdytintä ”customer.my.salesforce.com”-toimialueessa, sinun täytyy päivittää alkuperä ja työntää kokoonpano staging-ympäristöön CDN-verkossa ennen huoltoa. Sinun tulisi testata, että suora pääsy ja staging-ympäristö toimivat odotetulla tavalla välittömästi huollon jälkeen ennen käyttöönottoa tuotantoympäristössä.
b. Jos käytät kiihdytintä myös VisualForce- tai ContentForce-toimialueissasi (esim. customer--c.$NA10.content.force.com), sinun täytyy hankkia uusi SSL-sertifikaatti, johon sisältyy customer.my.salesforce.com sekä VisualForce- ja/tai ContentForce-toimialueiden alkuperäiset ja uudet instanssit (esim. $customer--c.NA10.content.force.com ja $customer--c.NA42.content.force.com).
i. Sinun täytyy sitten jakaa nämä sertifikaatit kolmannen osapuolen CDN-verkkosi toimittajan kanssa ottaaksesi ne käyttöön.
ii. Kun SSL-sertifikaatti on otettu käyttöön, sinun täytyy päivittää CDN-kokoonpanosi uusilla VisualForce- ja/tai ContentForce-isäntänimillä ja kaikkien kolmen päätepisteen alkuperällä ja työntää ne staging-ympäristöön.
iii. Sinun tulisi testata, että suora pääsy ja staging-ympäristö toimivat odotetulla tavalla välittömästi huollon jälkeen ennen käyttöönottoa tuotantoympäristössä.
HUOMAA: Uuden sertifikaatin hankkiminen ja työskentely kolmannen osapuolen CDN-verkostosi toimittajan kanssa voi kestää useita päiviä, joten aloita työsi vähintään kaksi viikkoa ennen instanssin jakoa tai siirtoa.
HUOMAA: Jos sinulla on Akamaita käyttävä erikoistunut kiihdytin isäntänimestäsi OmaToimialue.my.salesforce.com, OmaToimialue.lightning.force.com, OmaToimialue--c.documentforce.com, OmaToimialue--PaketinNimi.visualforce.com, OmaToimialue--c.InstanssinNimi.content.force.com tai OmaToimialue--PaketinNimi.InstanssinNimi.visual.force.com, sinun täytyy päivittää alkuperä ja siirtää kokoonpano staging-ympäristöön CDN-verkon sisällä ennen huoltoa. Sinun tulisi testata, että suora pääsy ja staging-ympäristö toimivat odotetulla tavalla välittömästi huollon jälkeen ja ennen käyttöönottoa tuotantoympäristössä. Tämä on harvinainen kokoonpano. Jos et ole varma, mitä tämä tarkoittaa, se ei koske sinun organisaatiotasi.
Tämä erikoistyyppinen kiihdytin korvataan pian Salesfroce Edge -verkolla. Salesforce ei yleisesti tue isäntänimien lisäämistä tämäntyyppiseen erikoistuneeseen kokoonpanoon, ja sinun tulisi tehdä yhteistyötä Salesforce-tuen kanssa siirtyäksesi Salesforce Edge -verkkoon ja pyytää Salesforcen tutkimus- ja kehitysosastoa poistamaan erikoistuneen kiihdyttimen käyttämät DNS-kokoonpanon korvaukset.
18. Vaikuttaako instanssin päivitys kolmansien osapuolten integraatioihin?
Kolmansien osapuolten integraatioiden tulisi toimia normaalisti instanssin päivityksen jälkeen. Oman toimialueen ottaminen käyttöön saattaa kuitenkin vähentää kovakoodattujen viitteiden uudelleenohjauksiin liittyvää kestoa instanssin päivityksen jälkeen, joten suosittelemme sitä vahvasti.
19. Mistä löydän lisätietoja Salesforce-huollon seuraavista aiheista:
a. Yleisimpiä kysymyksiä kovakoodattujen viitteiden päivittämisestä -artikkeli
i. Työkalu kovakoodattujen viitteiden löytämiseen organisaatiostasi
ii. Kovakoodatut viitteet
iii. Sähköpostiviestiketjujen tunnukset
iv. WSDL-tiedostot
v. Sertifikaatit
vi. Live Agent
b. Miten Salesforce-huolto vaikuttaa organisaatiooni? -artikkeli.
i. Viikoittaiset viennit
ii. Fyysinen poisto
iii. Kumppaniportaalit
c. Salesforcen IP-osoitealueet -artikkeli
i. IP-osoitealueet
ii. Sähköpostiasetukset
20. Mitä teen, jos minulla on Live Agent- tai SOS-toteutus?
Jos verkkosivustosi tai sertifikaattisi sisältävät kovakoodattuja viitteitä, jotka osoittavat Live Agentin päätepisteen URL-osoitteeseen, instanssin päivitys, organisaation siirto tai sijainnin vaihto saattaa vaikuttaa Live Agent-/SOS-ominaisuuteesi. Minimoi vaikutukset noudattamalla suositeltuja käytäntöjä, välttämällä päätepisteeseen osoittavia kovakoodattuja viitteitä ja varmistamalla, että päivität käyttöönottokoodissa olevan päätepisteen URL-osoitteen Määritykset-valikon Käyttöönotto-sivulta. Tarjoamamme käyttöönottokoodi voi uudelleenohjata uuteen palvelimeen, mutta sinun tulisi silti päivittää päätepiste välittömästi päivityksen jälkeen. Lisätietoja Live Agent -päätepisteistä ja kovakoodatuista päätepisteistä on artikkelissa Live Agent -palvelin (päätepisteen URL) on muuttunut eikä Live Agent Chat toimi enää.
21. Miten Salesforce ilmoittaa instanssin päivityksestä asiakkaille?.
a. Salesforce ilmoittaa kaikille asiakkaille toimenpiteitä vaativista huoltotoimista, jotta he ovat tietoisia ajoitetusta huoltojaksosta ja valmiina siihen. Salesforce lähettää ennen instanssin huoltopäivitystä sähköpostitse tuote- ja palveluilmoituksia pääkäyttäjille (eli käyttäjille, joilla on kaikkien tietojen muokkausoikeus ja kaikkien käyttäjien hallintaoikeus). Lisätietoja onTuote- ja palveluilmoitukset -artikkelissa.
b. Näiden sähköposti-ilmoitusten lisäksi Salesforce lähettää yhteenvedon asiakkaisiin vaikuttavista huoltotoimista Trailblazer Community -yhteisön Service Delivery (inc Hyperforceen) -ryhmään.
c. Kaikki huoltojaksot on ilmoitettu sivustolla trust.salesforce.com.
22. Haluaisin lisätietoja multitenant-arkkitehtuuristamme. Mistä löydän niitä?
a. Suorita Trailhead-ohjeistus Understanding the Salesforce Architecture.
b. Lisätietoja saat Salesforce-kehittäjien kirjoittamasta Multitenant Architecture -blogiviestistä.
23. Miten instanssin päivitys vaikuttaa aiemmin ajoitettuihin toimintoihin (viikoittaiset viennit, Apex-työt jne.) ja Apex-kutsuihin?
Käynnissä olevat toiminnot keskeytetään ennen instanssin päivitystä, ja niitä jatketaan instanssin päivityksen jälkeen. Instanssin päivityksen aikana ajoitetut toiminnot käynnistetään huoltojakson jälkeen.
Jotkin ennen instanssin päivitystä käynnistetyt Apex-, Batch Apex-, REST API-, SOAP API- ja Bulk API -työt saattavat palauttaa virheen huoltojakson jälkeen. Jos aiemmin ajoitettu työ aiheuttaa virheen huoltojakson jälkeen, työn käynnistäminen uudelleen palauttaa odotetut tulokset. Suosittelemme ajoittamaan suuret tai pitkäkestoiset työt instanssin päivityksen jälkeen, jotta ne toimisivat saumattomasti.
Ulkoisiin palveluihin tehdyt Apex-kutsut suoritetaan edelleen huollon aikana, ja koska ne johtavat usein muihin DML-kutsuihin Salesforce-sovellukseen, saatat huomata ongelmia suunnitelluissa ohjelmakuluissa, koska sovellus on Vain luku -tilassa. Suosittelemme estämään näiden kutsujen suorittamisen Vain luku -tilassa. Lisätietoja näiden kutsujen estämisestä on Apex Callouts in Read-Only Mode -asiakirjassa.
24. Siirretäänkö Trust-ilmoitukset uuteen instanssiin?
a. Instanssien päivitykset: Ennen instanssin päivitystä Salesforce määrittää kaikki lähdeinstanssin tilaajat olemaan automaattisesti kohdeinstanssin tilaajia. Huomaathan, että jos instanssi jaetaan kahdeksi erilliseksi instanssiksi, tilaajat tulevat olemaan molempien kohdeinstanssien tilaajia ja heidän täytyy päivittää tilausasetuksensa mahdollisimman pian.
b. Organisaatioiden siirrot: Tilausasetuksiasi ei päivitetä automaattisesti organisaation siirron jälkeen. Suosittelemme, että päivität tilausasetuksesi mahdollisimman pian, kun saat tietää uudesta instanssistasi, jotta saat sinulle tärkeitä tilapäivityksiä jatkossakin.
25. Mitä minun tulisi ottaa huomioon, jos käytän myös Herokua?
Lue tämä Herokun artikkeli: https://help.heroku.com/0HFMVV4B/what-do-i-need-to-do-about-my-upcoming-salesforce-instance-refresh
26. Mitä raskaissa sovellusalustan tapahtumissa ja muutosdatan kaappauksessa tulee ottaa huomioon?
a. Tietyt Salesforcen huoltotoimenpiteet (esim. organisaatioiden siirrot ja instanssien päivitykset) edellyttävät organisaation siirtoa toiseen datakeskukseen tai toiseen laitteistopinoon. Näiden toimintojen aikana fyysisesti siirrämme tietosi ja suoritamme ohjelmiston, joka toimittaa sovelluksesi toiseen laitteistoon. Tapahtumaväylän hajautetun ja asynkronisen luonteen takia emme pysty siirtämään kaikkia tapahtumia, jotka julkaistiin ennen instanssin päivitystä.
b. Instanssin päivityksellä ei ole vaikutusta tapahtumien reaaliaikaiseen toimittamiseen huoltoa ennen ja sen jälkeen, mutta kaikkien tapahtumien 72 tunnin säilytysjaksoa ei säilytetä. ReplayID-tunnukset tunnistavat yksilöllisesti tapahtumavirran hetken, jolloin tietty tapahtuma julkaistiin, ja koska organisaatiosi fyysinen sijainti on muuttunut, juuri julkaistujen tapahtumien ReplayIDs-arvoilla ei ole suhdetta tapahtumiin, jotka on julkaistu ennen siirtoa tai instanssin päivitystä. Sovellusalustan tapahtumien ja muutostapahtumien tilaajiin sisältyvät Streaming API (CometD) ‑asiakassovellukset, empApi Lightning ‑komponentit, Pub/Sub API ‑asiakassovellukset, tapahtumien välitys, Apex-käynnistimet ja kulut.
Katso myös: Platform Events Developer Guide: Publishing Events in Read-Only Mode
27. Mitä minun täytyy tehdä, jos Einstein-botit ovat käytössä organisaatiossani?
Siirry Määritykset-valikon Einstein-botit-sivulle huollon jälkeen. Poista Einstein-botit-ominaisuus käytöstä ja ota se uudelleen käyttöön. Tämä käynnistää organisaation uuden todennuksen Einstein.AI-palvelun kanssa.
28. Säilytetäänkö tapahtumalokien tiedot ja ovatko ne käytettävissä instanssin päivityksen jälkeen?
Ei, mutta suurin osa siirretään. Lokitiedot, joita ei ole käsitelty ennen organisaation siirtoa eivät ole käytettävissä uudessa instanssissa. Kun siirto alkaa, senhetkisen päivämäärän ja siirron valmistumispäivän välisiä tietoja ei siirretä uudessa sijainnissa olevaan organisaatioon. Tämä johtuu siitä, että tapahtumien valvonta täyttää valvontatapahtumat lokitietojen ja öisen eräprosessin avulla.
29. Mistä löydän lisätietoja, jos minulla on kysyttävää?
a. Voit myös lähettää kysymyksiä ja tehdä yhteistyötä muiden Salesforce-käyttäjien kanssa Trailblazer Community -yhteisön Official: Salesforce Infrastructure -ryhmässä.
b. Jos sinulla on vielä kysyttävää, lähetä asiakaspalvelulle tukitapaus Salesforce-ohjeportaalista.
30. Tunnettu ongelma
000387056

We use three kinds of cookies on our websites: required, functional, and advertising. You can choose whether functional and advertising cookies apply. Click on the different cookie categories to find out more about each category and to change the default settings.
Privacy Statement
Required cookies are necessary for basic website functionality. Some examples include: session cookies needed to transmit the website, authentication cookies, and security cookies.
Functional cookies enhance functions, performance, and services on the website. Some examples include: cookies used to analyze site traffic, cookies used for market research, and cookies used to display advertising that is not directed to a particular individual.
Advertising cookies track activity across websites in order to understand a viewer’s interests, and direct them specific marketing. Some examples include: cookies used for remarketing, or interest-based advertising.