globale
- Integrazioni di Adobe Acrobat Sign
- Novità
- Versioni del prodotto e ciclo di vita
- Acrobat Sign per Salesforce
- Installare il pacchetto
- Configurare il pacchetto
- Guida utente
- Abilitare l’autenticazione dell’identità digitale
- Guida per sviluppatori
- Guida alla personalizzazione avanzata
- Guida alla mappatura dei campi e ai modelli
- Guida utente dell’app per dispositivi mobili
- Guida all’automazione dei flussi
- Guida di Document Builder
- Configurare documenti di grandi dimensioni
- Guida all’aggiornamento
- Note sulla versione
- Domande frequenti
- Guida alla risoluzione dei problemi
- Articoli aggiuntivi
- Acrobat Sign per Microsoft
- Acrobat Sign per Microsoft 365
- Acrobat Sign per Outlook
- Acrobat Sign per Word/PowerPoint
- Acrobat Sign per Teams
- Acrobat Sign per Microsoft PowerApps e Power Automate
- Connettore Acrobat Sign per ricerca Microsoft
- Acrobat Sign per Microsoft Dynamics
- Acrobat Sign per Microsoft SharePoint
- Panoramica
- SharePoint On-Prem: guida all’installazione
- SharePoint On-Prem: guida alla mappatura dei modelli
- SharePoint On-Prem: guida utente
- SharePoint On-Prem: note sulla versione
- SharePoint Online: guida all’installazione
- SharePoint Online: guida alla mappatura dei modelli
- SharePoint Online: guida utente
- SharePoint Online: guida alla mappatura dei moduli web
- SharePoint Online: note sulla versione
- Acrobat Sign per Microsoft 365
- Acrobat Sign per ServiceNow
- Acrobat Sign per HR ServiceNow
- Acrobat Sign per SAP SuccessFactors
- Acrobat Sign per Workday
- Acrobat Sign per NetSuite
- Acrobat Sign per SugarCRM
- Acrobat Sign per VeevaVault
- Acrobat Sign per Coupa BSM Suite
- Acrobat Sign per Zapier
- Documentazione per sviluppatori Acrobat Sign
Panoramica
La Guida per sviluppatori di Adobe Acrobat Sign for Salesforce è progettata per consentire agli sviluppatori Salesforce di conoscere gli oggetti e i parametri necessari per integrare il pacchetto Salesforce con Adobe Acrobat Sign.
Per ulteriori informazioni, fai riferimento agli argomenti nel documento seguente:
Gli oggetti di Adobe Acrobat Sign for Salesforce potrebbero cambiare in una versione futura.Se crei una soluzione personalizzata che dipende da oggetti che subiscono modifiche, potrebbe essere necessario aggiornare la personalizzazione.
- Se hai bisogno di sapere quando l’accordo è stato completamente firmato, implementa un trigger Apex sull’oggetto echosign_dev1__SIGN_Agreement__c, prima o dopo l’aggiornamento (a seconda dei casi di utilizzo e dei requisiti). Quando il campo echosign_dev1__Status__c cambia in Firmato o Approvato o altri stati finali, l’accordo risulta completato.
- Per sapere quando viene inserito ogni singolo PDF firmato, ad esempio se hai bisogno di ottenere ogni PDF firmato intermedio, implementa un trigger Apex sugli oggetti Attachment o ContentVersion, dopo l’inserimento, e osserva se vi è un accordo principale e un nome che termina con “- firmato.pdf” o “- approvato.pdf” o un altro stato finale.
- Per sapere quando un singolo destinatario ha firmato o approvato un documento, implementa un trigger Apex sull’oggetto echosign_dev1__SIGN_Recipients__c, prima o dopo l’aggiornamento (a seconda dei casi di utilizzo e dei requisiti). Quando il campo echosign_dev1__Status__c diventa Firmato o Approvato o altri stati finali, il destinatario risulta completato.
- Per sapere quando si verifica un particolare evento del processo di firma, ad esempio quando un accordo viene inviato per la firma o quando viene inviato un promemoria, puoi creare un trigger nell’oggetto eventi accordo (echosign_dev1__SIGN_AgreementEvent__c) e verificare il tipo di evento
- I nomi per lo stato finale di un accordo completato sono: “Firmato”, “Approvato”, “Accettato”, “Compilato” e “Consegnato”
- I nomi per lo stato finale di un accordo terminato sono: “Annullato/Rifiutato”, “Annullato/Rifiutato”, “Scaduto”
Nella versione 21 l’ordine degli aggiornamenti è cambiato. Di seguito è riportata la sequenza di aggiornamento dell’accordo e dei suoi oggetti correlati:
- Allegati
- Destinatari
- Accordo (stato e altri attributi)
- Eventi accordo
- Feed di Chatter
Metodo Apex in uso
Avviando Acrobat Sign for Salesforce V21.0, tutti i processi asincroni (inclusi gli aggiornamenti automatici e le mappature dei dati) utilizzano il metodo Queueable anziché il metodo Future, come consigliato da Salesforce.
A seguito di questa modifica, tutti i processi di personalizzazione aggiunti alla coda di Salesforce per l’aggiornamento automatico o il processo di mappatura dei dati avranno esito negativo con questo errore: “System.LimitException: troppi processi queueable aggiunti alla coda:2.”
L’errore si verifica perché un processo queueable può aggiungere solo un processo queueable secondario che è già assunto da Acrobat Sign. Per informazioni dettagliate, fai riferimento a Limiti Queueable di Apex.
Quando lo stato dell’accordo non cambia o la mappatura dati non viene eseguita correttamente, potrebbe essere visualizzato questo errore: “Quando si concatenano più processi, è possibile aggiungere un solo processo da un processo in esecuzione con System.enqueueJob, il che significa che per ogni processo queueable principale può esistere un solo processo secondario. Non è possibile avviare più processi secondari da uno stesso processo queueable.”
Per risolvere tale errore, individua il trigger, il generatore di processi o il flusso di lavoro responsabile e disattivalo oppure cambialo per usare una chiamata sincrona o pianificalo in un secondo momento.
Servizio modelli di accordo
Il servizio modelli di accordo viene visualizzato come servizio Apex globale dal pacchetto gestito. Questo consente al codice Apex esterno al pacchetto gestito di caricare gli accordi in base ai modelli di accordo esistenti. La classe e tutti i metodi esposti sono contrassegnati come globale per consentire tale accesso.
Il servizio Apex viene esposto tramite la seguente classe di chiamata: echosign_dev1.AgreementTemplateService
Metodi
|
static Id load() |
Carica un accordo utilizzando un modello di accordo contrassegnato come predefinito e che non ha un tipo di oggetto principale. |
globale |
static Id load(String templateId) |
Carica un accordo utilizzando l’ID del modello di accordo specificato, che non ha un tipo di oggetto principale.
|
globale |
static Id load(String templateId, String masterId) |
Carica un accordo utilizzando l’ID del modello di accordo specificato e l’ID del record principale specificato, il cui tipo deve corrispondere al tipo di oggetto principale configurato nel modello di accordo specificato. |
globale |
static Id load(String templateId, String masterId, Map<String,AgreementTemplateVariable> agreementTemplateVariables) |
Carica un accordo utilizzando l’ID del modello di accordo specificato e l’ID del record principale specificato, il cui tipo deve corrispondere al tipo di oggetto principale configurato nel modello di accordo specificato. Trasmette anche le variabili di runtime specificate come coppie nome-valore.
|
globale |
static List<AgreementTemplateService.AgreementTemplateBasicInfo> getAgreementTemplateList(AgreementTemplateListOptions options) |
Consente di ottenere un elenco dei modelli di accordo in base alle opzioni di filtro. Se non viene trovato alcun modello di accordo con le opzioni di filtro, restituisce un elenco vuoto. |
globale |
static AgreementTemplateService.AgreementTemplateDetails getAgreementTemplateDetails(String templateId) |
Consente di ottenere i dettagli del modello di accordo per l’ID del modello di accordo specificato. Se non viene trovato un modello di accordo, restituisce un oggetto vuoto. |
globale |
static String getAgreementTemplateUrl(String templateId) |
Consente di ottenere l’URL per modificare il modello di accordo dato il relativo ID. |
globale |
static String getNewAgreementTemplateUrl() |
Consente di ottenere l’URL per creare un nuovo modello di accordo in Adobe Sign. |
Costruttori
Accesso |
Firma |
---|---|
globale |
AgreementTemplateListOptions() |
globale |
AgreementTemplateListOptions(String masterObjectType, Boolean isActive, Boolean hasAttachment, Boolean hasRecipient, Boolean autoSend) |
Proprietà classe globale
Accesso |
Nome |
---|---|
globale |
masterObjectType |
globale |
isActive |
globale |
hasAttachment |
globale |
hasRecipient |
globale |
autoSend |
Se un campo sopra elencato ha un valore null, quando si eseguono query sui modelli di accordo, non viene applicato alcun filtro al campo corrispondente.
Accesso |
Nome |
---|---|
globale |
name |
globale |
recordId |
globale |
url |
globale |
isDefault |
globale |
daysUntilExpiration |
globale |
language |
Accesso |
Nome |
---|---|
globale |
message |
globale |
ccList |
globale |
dataMappingName |
globale |
mergeMappingName |
globale |
url |
globale |
recipients |
Accesso |
Nome |
---|---|
globale |
recipientRole |
globale |
recipientType |
globale |
recipientName |
globale |
signOrder |
Variabili di runtime
La classe globale echosign_dev1.AgreementTemplateVariable dispone dei due campi globali seguenti:
- nome: nome della variabile che deve corrispondere al nome della variabile di runtime configurata nel modello di accordo.
- valore: valore della variabile utilizzato durante il caricamento del modello. Il valore dipende dalla posizione in cui è stata utilizzata la variabile. Ad esempio, per un destinatario deve essere un contatto, un lead o un ID record utente o un’e-mail. Per una variabile documento, deve essere un ID record allegato.
Risultato
Ogni metodo restituisce l’ID del record dell’accordo appena creato o genera un’eccezione con un messaggio di errore dettagliato se si è verificato un errore durante l’operazione di caricamento.
Il servizio del modello API di firma elettronica di Adobe viene visualizzato come servizio Apex globale dal pacchetto gestito. Questo consente al codice Apex esterno al pacchetto gestito di richiamare un set di API di firma elettronica di Adobe tramite questi wrapper. I wrapper semplificano notevolmente la chiamata API perché i clienti non devono creare modelli di dati di richiesta e di risposta. Inoltre, i clienti non devono gestire la trasformazione dei dati Salesforce in modelli di dati con firma elettronica. La maggior parte della complessità è astratta dal cliente. Ad esempio, per inviare un accordo appena trasmesso dal cliente nell’ID del record dell’accordo, il servizio gestirà la relativa query estraendo tutti i dati pertinenti trasmettendoli all’API e analizzando il risultato.
Per consentire tale accesso, la classe e tutti i metodi esposti sono contrassegnati come globali.
- La v17 e le versioni precedenti richiamano le API SOAP
- La v18 e le versioni successive richiamano le API REST
Il servizio Apex viene esposto tramite la seguente classe di chiamata: echosign_dev1.EchoSignApiService
Miglioramento delle API Apex per i destinatari alternativi
A partire dalla versione 24.14 o successiva, l’API Apex aggiornata consente di sostituire o aggiungere destinatari alternativi ed è accessibile all’interno della classe globale “EchoSignApiService,” sono stati introdotti due nuovi elementi:
- Una funzione globale:
/**
* Parametri di input:
* toBeChangedRecipientId: SIGN_Recipient__c Id
* newRecipientStr: stringa JSON di SIGN_Recipient__c di un nuovo destinatario per la sostituzione o l’alternativa del destinatario
* changeType: REPLACE o ALTERNATE
*/
global static void changeRecipient(Id toBeChangedRecipientId, String newRecipientStr, RECIPIENT_CHANGE_TYPE changeType )
- Enumerazione globale: RECIPIENT_CHANGE_TYPE {REPLACE, ALTERNATE}
Codice di esempio per chiamare questa API per i destinatari (tipo destinatario come e-mail)
// esegue una query su tutti i destinatari associati all’accordo
Elenco<SIGN_Recipients__c> recipients = [SELECT Id, echosign_dev1__Agreement__c, echosign_dev1__Email_Address__c, echosign_dev1__ParticipantSet__c, echosign_dev1__Recipient_Type__c, echosign_dev1__Order_Number__c FROM echosign_dev1__SIGN_Recipients__c where echosign_dev1__Agreement__c = 'a0P7X000008Cc1GUAS'];
SIGN_Recipients__c newRecipient = null;
SIGN_Recipients__c replacedRecipient = null;
// trova il destinatario da sostituire o un destinatario alternativo
// in questo caso, trova il destinatario tramite e-mail.
// È possibile aggiungere altre condizioni per trovare il destinatario da sostituire o che necessita di un destinatario alternativo.
for(SIGN_Recipients__c recipient: recipients) {
if (rep.echosign_dev1__Email_Address__c == 'someUser@example.com') {
newRecipient = recipient.clone(false, true, false, false);
replacedRecipient = recipient;
}
}
// aggiorna l’indirizzo e-mail del nuovo destinatario
newRecipient.echosign_dev1__Email_Address__c = ''someNewUser@abc.com';
// serializzalo in una stringa json
String newRecipientStr = JSON.serialize(newRecipient);
Prova {
echosign_dev1.EchoSignApiService.changeRecipient(replacedRecipient.Id, newRecipientStr, EchoSignApiService.RECIPIENT_CHANGE_TYPE.REPLACE);
} catch (Exception ex) {
// gestisci l’eccezione e rilancia se necessario
}
Metodi
globale |
static void cancelDocument(Id agreementId) |
Annulla l’accordo con l’ID accordo specificato. |
globale |
static echosign_dev1.EchoSignApiService.DocumentInfo getDocumentInfo(Id agreementId) |
Recupera informazioni dettagliate per l’ID accordo specificato. |
globale |
static List<EchoSignApiService.SigningUrl> getSigningUrls(Id agreementId) |
Recupera tutti gli URL di firma per l’ID accordo specificato. |
globale |
static void removeDocument(Id agreementId) |
Annulla l’accordo con l’ID accordo specificato ed elimina il record dell’accordo in Salesforce (l’accordo non viene rimosso dall’account Adobe con firma elettronica). |
globale | static void replaceSigner(Id replacementRecipientId) |
Obsoleto per V 24.14. Le versioni del pacchetto precedenti a v24.14 possono ancora utilizzarle poiché si basano sulle API V5. |
globale | static void replaceSigner(Id replacementRecipientId, String message) |
Obsoleto per V 24.14. Le versioni del pacchetto precedenti a v24.14 possono ancora utilizzarle poiché si basano sulle API V5. |
globale |
static echosign_dev1.EchoSignApiService. SendDocumentResult sendDocument(Id agreementId) |
Invia l’accordo con l’ID accordo specificato, restituisce il risultato con la chiave del documento e gli URL. |
globale |
static void sendReminder(Id agreementId) |
Invia un promemoria al firmatario corrente per l’ID accordo specificato. |
globale | static void updateAgreement(Id agreementId) | Aggiorna l’accordo con il valore agreementId specificato |
globale | static EchoSignApiService.AgreementViewUrl getViewAgreementUrl(Id agreementId) |
Recupera la pagina di visualizzazione/gestione da Sign per l’ID accordo specificato che dispone di una proprietà di visualizzazione. Nota: per motivi di sicurezza, l’URL dell’accordo generato ha una durata temporanea, quindi genera una chiamata REST-HTTPS per ottenere un URL nuovo dai servizi di Adobe Sign. |
globale | static void changeRecipient(Id toBeChangedRecipientId, String newRecipientStr, EchoSignApiService.RECIPIENT_CHANGE_TYPE changeType ) | Questa API è disponibile a partire dalla versione 24.14 e modifica i destinatari dell’accordo. |
Classi interne
- Classe globale:DocumentHistoryEvent
Accesso |
Nome |
---|---|
globale |
String eventType |
globale |
String participantEmail |
Accesso |
Firma |
---|---|
globale |
DocumentHistoryEvent() |
- Classe globale: DocumentInfo
Accesso |
Nome |
---|---|
globale |
Map<string,list> historyByEmail |
globale |
Map<String,EchoSignApiService.ParticipantInfo> |
globale |
Map<String,EchoSignApiService.ParticipantInfo> |
globale |
String senderEmail |
globale |
Stringa stato |
Accesso |
Firma |
---|---|
globale |
DocumentInfo() |
- Classe globale: ParticipantInfo
Accesso |
Nome |
---|---|
globale |
Stringa azienda |
globale |
Stringa e-mail |
globale |
Stringa nome |
globale |
Stringa stato |
globale |
Stringa titolo |
Accesso |
Firma |
---|---|
globale |
ParticipantInfo() |
- Classe globale: SendDocumentResult
Accesso |
Nome |
---|---|
globale |
String documentKey |
globale |
Errore eccezione |
globale |
URL stringa |
Accesso |
Firma |
---|---|
globale |
SendDocumentResult() |
- Classe globale: SigningUrl
Accesso |
Nome |
---|---|
globale |
Stringa e-mail |
globale |
String esignUrl |
globale |
String simpleEsignUrl |
Accesso |
Firma |
---|---|
Globale |
|
Espone le principali azioni degli accordi con firma elettronica a livello collettivo, consentendo l’esecuzione di un’operazione su una set di accordi. Questa classe implementa l’interfaccia Database.Batchable di Salesforce. Può elaborare un numero qualsiasi di record suddivisi in insiemi di 5 ed elaborare ogni insieme come una singola transazione consentendo di rispettare i limiti di gestione.
Il servizio batch Apex è esposto tramite la seguente classe di chiamata: echosign_dev1.EchoSignActionBatch
Parametri
Per inizializzare un’operazione batch, è necessario specificare i seguenti parametri:
- Un elenco degli ID record dell’accordo su cui eseguire l’azione fornita: l’azione può avere uno dei seguenti valori supportati: Promemoria, Invia, Annulla, Elimina o Aggiorna.
- Un ID della sessione utente corrente: obbligatorio solo per un tipo di azione di aggiornamento.
- Un record utente del mittente: utilizzato per avvisare l’utente tramite e-mail una volta completata l’elaborazione in blocco.
Esempio di utilizzo
User submitterUser = UserInfo.getUserId();
EchoSignActionBatch batch = new EchoSignActionBatch( agreementIds, 'Remind', UserInfo.getSessionId(), submitterUser); Id syncProcessId = Database.executeBatch(batch, 5);
Inserisce una query SOQL e l’ID del record di un modello di accordo. La query viene eseguita per ottenere un set di record dell’oggetto principale, ognuno dei quali viene quindi eseguito tramite il modello di accordo fornito per generare un record dell’accordo. Questa classe implementa l’interfaccia Database.Batchable di Salesforce. Può elaborare un numero qualsiasi di record suddivisi in insiemi di 5 ed elaborare ogni insieme come una singola transazione consentendo di rispettare i limiti di gestione.
I tipi di record restituiti dalla query SOQL devono corrispondere al tipo di oggetto principale del modello di accordo fornito. Per ogni record, viene richiamato il servizio del modello di accordo.
Il servizio batch Apex è esposto tramite la seguente classe di chiamata:
echosign_dev1.AgreementTemplateBatch
Parametri
Per inizializzare un’operazione batch, è necessario specificare i seguenti parametri:
- query SOQL da eseguire: deve contenere l’ID record come campo selezionato. Altri campi sono facoltativi.
- ID record del modello di accordo: è utilizzato insieme all’ID record principale per caricare un accordo.
Esempio di utilizzo
String agreementTemplateId = [SELECT Id from echosign_dev1__Agreement_Template__c where Name = 'Default Template']; String soqlQuery = 'SELECT Id from Contact where Account.IsActive = true';
AgreementTemplateBatch batch = new AgreementTemplateBatch(soqlQuery, agreementTemplateId); Id syncProcessId = Database.executeBatch(batch, 5);
Consente di visualizzare un elenco degli ID del record dell’oggetto principale e del tipo di oggetto principale che sono sottoposti a query, ognuno dei quali viene quindi eseguito tramite il modello di accordo fornito per generare un record dell’accordo. Questa classe implementa l’interfaccia Database.Batchable di Salesforce. Può elaborare un numero qualsiasi di record suddivisi in insiemi di 5 ed elaborare ogni insieme come una singola transazione consentendo di rispettare i limiti di gestione.
Il tipo di oggetto principale fornito deve corrispondere al tipo di oggetto principale del modello di accordo fornito. Per ogni record, viene richiamato il servizio del modello di accordo.
Il servizio batch Apex è esposto tramite la seguente classe di chiamata:
echosign_dev1.AgreementTemplateServiceBatch
Parametri
Per inizializzare un’operazione batch, è necessario specificare i seguenti parametri:
- Elenco degli ID record principali.
- ID record del modello di accordo: è utilizzato insieme ai record principali per caricare un accordo.
- È necessario eseguire una query del nome oggetto principale per i record master.
Esempio di utilizzo
String agreementTemplateId = [SELECT Id from echosign_dev1__Agreement_Template__c where Name = 'Default Template'];
AgreementTemplateBatch batch = new AgreementTemplateServiceBatch(new List<Id>{'01p50000000HoMB'}, agreementTemplateId, 'Contact');
Id syncProcessId = Database.executeBatch(batch, 5);
Servizio modelli di accordo
Il servizio del modello di accordo viene visualizzato dal pacchetto gestito come servizio Web REST di Salesforce. Ciò consente ai sistemi esterni al di fuori dell’organizzazione di Salesforce di caricare gli accordi in base ai modelli di accordo esistenti. Per ulteriori dettagli su come accedere e richiamare i servizi personalizzati REST Apex da Salesforce, consulta l’articolo Creazione di API REST con Apex REST Le chiamate devono fornire un ID di sessione valido per l’autenticazione e l’autorizzazione.
Il servizio Web è accessibile dal seguente URL:
https://<instance_name>.salesforce.com/services/apexrest/echosign_dev1/template/load/<template_id>?masterId=<master_id>&varName1=var Value1&varName2=varValue2
- Il nome dell’istanza varia a seconda dell’istanza dell'organizzazione.
- https://_<instance_name>_.salesforce.com/services/apexrest/echosign_dev1/template/load/<template_id> è un metodo HTTP POST per il pacchetto delle versioni 20.0 e successive.
- Le versioni precedenti alla 20 utilizzano un metodo GET.
ID modello
L’ultima parte dell’URL è l’ID della registrazione del modello di accordo nell’organizzazione di Salesforce corrente che deve essere utilizzato per caricare l’accordo. Questa parte dell’URL è facoltativa. Se omessa, verrà caricato il modello di accordo contrassegnato come predefinito. Se l’ID modello è omesso e non esiste un ID modello per l’accordo predefinito, verrà restituito un errore.
L’ID modello può avere un formato di 15 o 18 caratteri.
ID principale
Il parametro masterId specifica quale record principale deve essere utilizzato per caricare l’accordo dal modello di accordo specifico. Questo parametro è facoltativo, ma deve essere indicato per qualsiasi modello di accordo che specifica un tipo di oggetto principale e fa riferimento a tale oggetto principale nel modello.
L’ID principale può avere un formato di 15 o 18 caratteri.
Variabili di runtime
Tutti i parametri aggiuntivi vengono utilizzati come variabili di runtime, come coppie di valori nome, per popolare le variabili di runtime specificate nel modello di accordo.
Risultato
Il servizio Web REST restituisce un oggetto LoadResult che contiene i seguenti campi:
- agreementId: se l’operazione di caricamento dell’accordo è riuscita, questo campo contiene l’ID del record dell’accordo appena creato.
- error: in caso di errore durante il caricamento dell’accordo, questo campo contiene un messaggio di errore dettagliato.
La funzionalità di servizio in background consente ai clienti del pacchetto di richiamare varie azioni su un oggetto dell’accordo aggiornando il campo Azione in background (echosign_dev1 Background_Actions c) al valore corrispondente. Una volta modificato il valore del campo da un valore vuoto o da un altro valore a uno dei valori seguenti, l’azione viene avviata da un trigger incluso nel pacchetto di firma elettronica gestito.
- Promemoria
- Invia
- Annulla
- Elimina
- Aggiorna
Tutte le azioni vengono eseguite in modalità asincrona futura, quindi lo stato viene memorizzato nel campo Errore dell’accordo.
- Lo stato dell’accordo ora viene aggiornato dopo l’aggiornamento dei documenti e dei destinatari.
- Prima della versione 21, lo stato veniva impostato prima.
- L’oggetto Accordo firmato (in cui sono memorizzati gli URL immagine) ora non viene inserito affatto.
- Prima della versione 21 veniva inserito dopo il completamento di tutti gli altri aggiornamenti.
- La dimensione massima delle richieste o risposte di callout è di 12 MB per codice Apex asincrono in base ai limiti di Salesforce: https://developer.salesforce.com/docs/atlas.en-us.210.0.apexcode.meta/apexcode/apex_gov_limits.htm
- A causa di tale limite, non è possibile recuperare da Sign documenti di dimensioni superiori a 12 MB.
- Sono state modificate le descrizioni degli eventi dell’accordo. Ora corrispondono alle descrizioni restituite dall’API di Sign e presenti nei report di audit.
- Il processo di aggiornamento ora viene eseguito come processo batch Apex nativo (processo asincrono) in Salesforce.
- Precedentemente era un aggiornamento basato su chiamate API dall’esterno di Salesforce.
- I trigger attivati da tali aggiornamenti di stato che avviano processi asincroni non funzionano più, in quanto Salesforce limita la chiamata di un altro processo asincrono da parte di un processo asincrono già in esecuzione.
- Prima della versione 21, gli aggiornamenti degli attributi degli accordi venivano suddivisi in chiamate di aggiornamento separate; ora l’oggetto accordo viene aggiornato in una singola transazione.
- Prima della versione 21, gli accordi non riusciti potevano essere ritentati solo mediante un aggiornamento manuale dall’interno di Salesforce.
- Ora gli aggiornamenti sono più affidabili in quanto il backend di Sign ritenta automaticamente gli eventi non riusciti per un determinato numero di volte.
- Gli aggiornamenti manuali ora aggiornano tutti gli aspetti degli accordi, inclusi gli oggetti correlati.
- Gli accordi push ora vengono eseguiti in modalità asincrona (come gli aggiornamenti regolari) e gli attributi aggiuntivi vengono aggiornati (come gli aggiornamenti regolari).
- Sono state introdotte nuove impostazioni per abilitare o disabilitare gli aggiornamenti dei diversi aspetti dell’accordo.
- Quando un PDF firmato viene archiviato in Salesforce, alla fine del nome del file PDF non verrà più aggiunto un descrittore (-firmato o -approvato).
Altri argomenti correlati
- Adobe Acrobat Sign for Salesforce - Guida all’installazione
- Guida avanzata alla personalizzazione di Adobe Acrobat Sign for Salesforce
- Mappatura di campi e modelli di Adobe Acrobat Sign for Salesforce
- Adobe Acrobat Sign for Salesforce - Guida all’aggiornamento
- Guida utente di Adobe Acrobat Sign for Salesforce