Päivitetty viimeksi 9. tammikuuta 2020
Yleisesti ottaen kovakoodattu viite on linkki, joka sisältää instanssisi nimen (esim. NA25, AP2, EU4, CS10 tms.). Jos Salesforce-organisaatiollesi suoritetaan huoltotoimenpiteitä, kuten instanssin päivitys tai organisaation siirto ja organisaatiollasi on kovakoodattuja viitteitä integraatioissasi, sähköpostimalleissasi, ohjeartikkeleissasi ja mukautuksissasi, niissä saattaa ilmetä häiriöitä. Esimerkiksi integraatiot saattavat rikkoutua ja sähköpostit voivat sisältää rikkinäisiä linkkejä ja kuvia. Jotta vältyt tämäntyyppisiltä häiriöiltä, suosittelemme käyttämään omaa toimialuetta ja tutustumalla oleviin yleisimpiin kysymyksiin.
HUOMAUTUS: 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.
Liittyvät artikkelit:
Yleisimpiä kysymyksiä
1. Mitä ovat kovakoodatut viitteet (eli instanssikohtaiset viitteet)?
a) Kovakoodattu viite on URL-osoite, joka sisältää instanssin nimen (esim. na1.salesforce.com). Korvaa kovakoodatut viitteet tarkoilla tai suhteellisilla URL-osoitteilla, jotka eivät sisällä instanssin nimeä (esim. login.salesforce.com tai <omatoimialue>.my.salesforce.com).
Tässä esimerkki kovakoodatusta viitteestä: https://na1.salesforce.com/{Case.Id}
Voit tehdä tästä suhteellisen viitteen poistamalla ”na1.salesforce.com”-osion, muuttaen sen muotoon: /{Case.Id}
HUOMAA: Salesforcessa suhteelliset viitteet ohjaavat sinut automaattisesti oikeaan tietueeseen. Ulkoiset pyynnöt tulisi lähettää yleiseen päätepisteeseen, kuten: https://login.salesforce.com, eikä https://na1.salesforce.com.
2. Miten löydän kovakoodatut viitteet?
a) Käytä Salesforcen Lightning Experience -valmiustarkistusta havaitaksesi kovakoodattuja viitteitä ja nähdäksesi, kuinka valmis olet Lightning Experiencea varten:
Lightningissa: avaa Määritykset | Lightning Experience | Tarkasta valmiutesi
Classicissa: avaa Määritykset | napsauta ”Lightning Experience -toteutusavustaja” -kohdan alapuolelta ”Aloita” | Tarkasta valmiutesi
Huomioi, ettei kaikki kovakoodattuja viitteitä löydetä Lightning Experience -valmiustarkistustyökalulla. Lisätietoja tämän työkalun raportoinnista on asiakirjassa Mitä kaikkea Lightning Experience -valmiustarkastus arvioi?
b) Hae kovakoodattuja viitteitä Salesforce Extensions for Visual Studio Code -koodille
Salesforce Extensions for Visual Studio Code on kehittäjien työkalu, jota voi käyttää kovakoodattujen viitteiden etsimiseen. Noudata artikkelin Salesforce-projektin luominen Visual Studio Codessa ja kovakoodattujen viitteiden hakeminen vaiheita päivittääksesi organisaatiossasi ja organisaatiosi metadatassa (määrityksissä tai mukautetussa koodissa) olevat kovakoodatut ohjeet*.
3. Miten päivitän integraatioissa olevat kovakoodatut viitteet?
Käytä Salesforce-tuotteiden integraatioissasi tai Force.com-integraatioissasi aloituspisteenä Force.com API:n pyyntöä login(). Pyyntö login() tulisi lähettää yleiseen päätepisteeseen, kuten: https://login.salesforce.com/services/Soap/u/26.0.
Kutsu login() aloittaa Force.com-istunnon ja vastaa sisäänkirjautumispalvelimen URL-osoitteella. Määritä tämä palvelimen URL tulevien API-pyyntöjen kohdepalvelimeksi ja aseta SOAP-otsakkeessa palautettu istuntotunnus tarjoamaan palvelinvaltuutus tuleville API-pyynnöille.
Instanssien päivityksiin ja organisaatioiden siirtoihin liittyviä yleisimpiä kysymyksiä
Kovakoodattuja viitteitä koskevat kysymykset saattavat olla hyödyllisiä, kun valmistaudut siirtymään uuteen instanssiin.
4. Mitä kovakoodattuja viitteitä Salesforce-palvelimet voivat uudelleenohjata uuteen instanssiin siirtymisen jälkeen?
Kaikkia kovakoodattuja viitteitä ei uudelleenohjata instanssin päivityksen tai organisaation siirron jälkeen, joten suosittelemme vahvasti ottamaan Oma toimialue -ominaisuuden käyttöön ja poistamaan kaikki kovakoodatut viitteet ennen muutosta. Alla on luettelo kohteista, jotka Salesforce-palvelimet voivat uudelleenohjata, mutta saatat huomata suorituskyvyn heikkenemistä käyttäessäsi näitä objekteja uuteen instanssiin siirtymisen jälkeen:
i. Selainlinkit
ii. Selaimien kirjanmerkkien URL-osoitteet
iii. Mukautetut painikkeet
iv. Sisällön URL-osoitteet
v. Chatter-viestit
vi. Itsepalvelun sisäänkirjautumissivujen URL-osoitteet (sserv/login.jsp?orgid)
vii. Integroinnit
5. Mitkä kovakoodatuista viitteistä täytyy päivittää (eli uudelleenohjata) ennen uuteen instanssiin siirtymistä?
Jos Oma toimialue -ominaisuus ei ole käytössäsi, sinun täytyy päivittää sähköpostimalleissa ja Knowledge-artikkeleissa olevat kovakoodatut viitteet.
Riippumatta siitä, onko Oma toimialue -ominaisuus käytössäsi vai ei, sinun täytyy varmistaa, että kaikki Knowledge-artikkeleissa ja sähköpostimalleissa olevat kuvat on ladattu tietokoneeltasi eivätkä osoita verkko-osoitteisiin, jotta ne näkyisivät edelleen huollon jälkeen.
i. Jos sinulla on verkko-osoitteen avulla lisättyjä kuvia, sinun täytyy ladata kuva tietokoneellesi ja lähettää se uudelleen valitsemalla ”Lataa kuva” -vaihtoehto, kun lisäät kuvaa Knowledge-artikkeliin tai sähköpostimalliin. Katso alla oleva kaavio nähdäksesi tietoja tästä prosessista.
HUOMAUTUS: Jos löydät huollon jälkeen kuvia, jotka eivät toimi, koska niitä ei ladattu tietokoneelta, sinun täytyy vaihtaa niiden URL-osoitteissa oleva vanhan instanssin nimi uuden instanssin nimellä. Sen jälkeen sinun tulisi ladata kuva tietokoneellesi ja lähettää se uudelleen tietokoneeltasi, jotta kuva toimisi myös tulevien huoltotoimien jälkeen.
6. Miten tarkastan, että Knowledge-artikkelissani ja sähköpostimalleissani olevat kuvat on ladattu tietokoneelta eivätkä osoita verkko-osoitteisiin?
Jos kuva on ladattu paikalliselta laitteelta, kuvan URL-osoitteen tulisi olla ”https://[ISÄNTÄ-TAI-OMA-TOIMIALUE]/servlet/rtaImage…”.
Jos kuva on linkitetty verkko-osoitteesta (tai Asiakirjat-välilehdestäsi), kuvan URL-osoitteen tulisi olla ”https://[ISÄNTÄ-TAI-OMA-TOIMIALUE]/servlet/servlet.ImageServer...” tai ”https://[ISÄNTÄ-TAI-OMA-TOIMIALUE]/servlet/servlet.FileDownload…”
7. Täytyykö minun päivittää CTI-integraatioissani olevat kovakoodatut viitteet, jos siirryn uuteen instanssiin?
Jos käytät Open CTI:tä ja Salesforce-instanssisi on kovakoodattu puhelukeskuksesi määritelmän CTI-adapterin URL-osoitteeseen (esim. https://c.na6-visual.force.com/apex/Softphone) tämä muutos vaikuttaa CTI-integraatioosi.
Muuta tämä kovakoodattu viite suhteelliseksi URL-osoitteeksi (esim. /apex/SoftPhone) varmistaaksesi, että CTI-integraatiosi toimii uuteen instanssiin siirtymisen jälkeenkin. Voit päivittää sen puhelukeskusobjektisi valintapolusta: Määritykset > Puhelukeskukset.
Jos käytössäsi on Salesforce Desktop CTI Integration Toolkit, tämä huoltotoimi ei vaikuta CTI-integraatioosi, sillä Toolkit ei salli kovakoodattuja viitteitä.
8. Täytyykö minun päivittää sähköpostiviestiketjujen tunnukset, jos siirryn uuteen instanssiin?
Jos olet luonut mukautettuja sähköpostiviestiketjujen tunnuksia, siirtyminen uuteen instanssiin saattaa vaikuttaa sinuun. Muussa tapauksessa sinun ei tarvitse päivittää Salesforcen luomia sähköpostiviestiketjujen tunnuksia uuteen instanssiin siirtymisen jälkeen (vaikka niissä viitattaisiin vanhojen instanssien nimiin).
Korjaa mukautetut sähköpostiviestiketjujen tunnukset noudattamalla seuraavia ohjeita:
i. Päivitä mukautettu kaavasi seuraavaan formaattiin: ref:_00D[XX][yyyyy]._500[AA][bbbbb]:ref
ii. jossa yyyyy ja bbbbb ovat 10-merkkinen tunnus ilman sen alussa olevia nollia.
iii. Järjestelmämme voi jäsentää seuraavat sähköpostiviestiketjujen tunnusten formaatit (yyyyy ja bbbbb ovat tietueen tunnus ilman sen alussa olevia nollia)
HUOMAA: ref:00DXyyyyy.500Abbbbb:ref on vanha formaatti, jota ei enää käytetä.
Salesforce saattaa muuttaa formaatteja ajan myötä, joten asiakkaiden tulisi välttää omien viestiketjujen tunnusten luomista. Jos mukautit viestiketjujen tunnuksiasi, sinulla saattaa esiintyä ongelmia Sähköpostista tapaukseksi tarvittaessa (E2C) -toiminnossa, joka luo uusia tapauksia kiinnittämättä niitä alkuperäiseen tapaukseen vastauksina. Älä luo viestiketjujen tunnuksille omia mukautettuja formaatteja. Emme virallisesti tue mukautettuja kaavoja tapausten viestiketjujen tunnuksille, joten suosittelemme asiakkaitamme käyttämään viestiketjujen tunnuksille Salesforcen tarjoamaa käyttövalmista kaavaa. Lisätietoja siitä, miksi sinun ei tulisi luoda mukautettua kaavaa, on artikkelissa Mukautettujen viestiketjujen tunnusten käyttäminen Sähköpostista tapaukseksi -toiminnon kanssa.
9. Voivatko asiakkaat käyttää kumppaniportaalia edelleen vanhan instanssin URL-osoitteesta uuteen instanssiin siirtymisen jälkeen?
Asiakkaiden tulisi voida käyttää kumppaniportaaliasi vanhan instanssin URL-osoitteesta noin 30 päivän ajan uuteen instanssiin siirtymisen jälkeen. Näiden 30 päivän jälkeen vanhan instanssin sisäänkirjautumissivun URL-osoite poistetaan käytöstä. Suosittelemme ennen uuteen instanssiin siirtymistä, että pääkäyttäjät luovat organisaatioidensa kumppaniportaalin "Järjestelmähuolto"-viestin alle mukautetun huomautuksen, joka ohjaa asiakkaat käyttämään portaalin uutta URL-osoitetta uuteen instanssiin siirtymisen jälkeen. Pääkäyttäjät voivat myös suositella asiakkaille, että he päivittävät kirjanmerkkinsä käyttämään kumppaniportaalin uutta URL-osoitetta.
10. Vaikuttaako uuteen instanssiin siirtyminen Webistä liidiksi-/Webistä tapaukseksi (W2X) -toimintoihin?
Jos W2X-toiminnoissasi on kovakoodattuja viitteitä, sinun täytyy päivittää ne suhteellisiksi URL-osoitteiksi ennen uuteen instanssiin siirtymistä. Jos et päivitä kovakoodattuja viitteitä, W2X-toiminnoissa saattaa esiintyä odottamattomia palveluhäiriöitä huoltotoimen jälkeen. W2X asetetaan jonoon ja käsitellään huoltotoimen jälkeen.
11. Täytyykö etäsivustojen nimet päivittää uuteen instanssiin siirtymisen jälkeen?
Kyllä. Jos et käytä Oma toimialue -ominaisuutta, etäsivustojen nimissä olevat kovakoodatut viitteet täytyy päivittää käyttämään uuden instanssin nimeä välittömästi huoltotoimenpiteen jälkeen.
Jos et päivitä etäsivustojen nimissä olevia kovakoodattuja viitteitä huollon jälkeen, etäsivustoissa saattaa esiintyä odottamattomia palveluhäiriöitä.
12. Vaikuttaako uuteen instanssiin siirtyminen Salesforce Mobile SDK -pakettiin?
Uuteen instanssiin siirtyminen saattaa vaikuttaa Salesforce Mobile SDK -paketilla luotujen sovellusten dataan, jos käyttäjillä ei ole uusinta versiota. Suosittelemme, että päivität kaikki Salesforce Mobile SDK -paketilla luodut tapaukset ja julkaiset nämä päivitykset kaikille organisaatiosi käyttäjille ennen huoltoa.
Jos käyttäjillä on kaikkien Salesforce Mobile SDK -paketilla luotujen sovellusten uusimmat versiot, uuteen instanssiin siirtymisen ei tulisi vaikuttaa niiden dataan.
13. Mitä minun täytyy tehdä, 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ää.
14. Mitä minun täytyy tehdä Apex-verkkopalveluiden luomille WSDL-tiedostoille?
Jos käytät WSDL-tiedostoja luodaksesi koodia, sinun täytyy tarkastaa kaikki paikat, johon olet lisännyt koodia, kovakoodattujen viitteiden varalta. Kaikki kovakoodatut viitteet täytyy päivittää osoittamaan joko oman toimialueesi URL-osoitteeseen tai suhteelliseen URL-osoitteeseen (login.salesforce.com). Suosittelemme ottamaan oman toimialueen käyttöön ennen uuteen instanssiin siirtymistä. Näin sinun ei tarvitse suorittaa tätä toimenpidettä uudelleen, kun olet korjannut kaikki kovakoodatut viitteet osoittamaan oman toimialueen uuteen URL-osoitteeseen.
000387070

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.