Adobe Acrobat Sign för Salesforce: användarhandbok för utvecklare

Adobe Acrobat Sign för Salesforce: Utvecklar guide är utformad för att hjälpa Salesforce-utvecklare att lära sig om de objekt och parametrar som krävs för att integrera ditt Salesforce-paket med Adobe Acrobat Sign.

Läs mer om de olika ämnena i detta dokument:

• Riktlinjer för utvecklare
• Uppdatera order
• Apex-tjänster
• API-tjänster
• Apex-grupptjänster
• Mallgrupp för avtal
• Tjänstgrupp för avtalsmall
• REST-tjänster
• Bakgrundstjänster
• Ändringar av bakåtkompatibilitet

• Om du behöver veta när avtalet är helt signerat implementerar du en Apex-utlösare på objektet echosign_dev1__SIGN_Agreement__c, efter eller före uppdatering (beroende på typ av användning och krav). När fältet echosign_dev1__Status__c ändras till Signerat eller Godkänt eller annan slutlig status, är avtalet slutfört. 
• Om du behöver veta när varje enskild signerad PDF-fil infogas, om du t.ex. behöver få varje mellanliggande signerad PDF-fil, ska du implementera en Apex-utlösare på objekten Attachment eller ContentVersion, efter infogning, och vara uppmärksam på ett överordnat avtal och ett namn som slutar på "signed.pdf" eller "approved.pdf" eller någon annan slutlig status
• Om du vill veta när en enskild mottagare har signerat eller godkänt implementerar du en Apex-utlösare på objektet echosign_dev1__SIGN_Recipients__c, efter eller före uppdatering (beroende på typ av användning och krav). När fältet echosign_dev1__Status__c ändras till Signerat eller Godkänt eller annan slutlig status, slutförs mottagaren.  
• Om du behöver veta när en viss händelse som ingår i signeringsprocessen inträffar, till exempel ett avtal som skickas för signering eller en påminnelse som skickas, kan en utlösare skapas på avtalshändelseobjektet (echosign_dev1__SIGN_AgreementEvent__c) och kontrollera händelsetypen
• Statusnamn för slutgiltiga avtal för ett slutfört avtal är: "Signerat", "Godkänt", "Accepterat", "Formulär ifyllt" och "Levererat"
  
• Statusnamn för det slutliga avtalet för ett avslutat avtal är: "Avbrutet/avvisat", "Avbrutet/avvisat", "Utgånget"

Ordningen för uppdateringar

I v21 har uppdateringsordningen ändrats. Nedan visas den nya sekvensen när avtal och relaterade objekt uppdateras:

1. Bifogade filer 
2. Mottagare 
3. Avtal (status och övriga attribut)
4. Avtalshändelser 
5. Chatter-flöden 

Apex-tjänster

Apex-metod som används

Från och med Acrobat Sign för Salesforce v 21.0 använder alla asynkrona processer (inklusive automatiska uppdateringar och datamappningar) kömetoden i stället för framtidsmetoden, som rekommenderas av Salesforce.
Med den här ändringen kommer alla anpassningsjobb som läggs till i Salesforce-kön för automatisk uppdatering eller datamappningsprocess att misslyckas med det här felet: "System.LimitException: för många köbara jobb har lagts till i kön:2."

Felet beror på att en köbar process bara kan lägga till ett köbart underordnat jobb, som redan är upptaget av Acrobat Sign. Mer information finns i Kögränser för Apex.

Om avtalets status inte ändras eller om datamappningen inte körs korrekt kan det här felet visas: "När du länkar jobb kan du bara lägga till ett jobb från ett körande jobb med System.enqueueJob, vilket innebär att bara ett underordnat jobb kan finnas för varje överordnat köbart jobb. Att starta flera underordnade jobb från samma köbara jobb stöds inte."

Lös felet genom att leta efter den felande utlösaren, processbyggaren eller arbetsflödet och inaktivera det eller ändra det till att använda ett synkront anrop eller schemalägga det till senare.

Avtalsmalltjänst

Avtalsmalltjänsten visas som en global Apex-tjänst av det hanterade paketet. Detta gör att Apex-kod utanför det hanterade paketet kan läsa in avtal som baseras på befintliga avtalsmallar. Klassen och alla exponerade metoder markeras som global för att medge sådan tillgång.

Apex-tjänsten visas via denna anropsklass: echosign_dev1.AgreementTemplateService

Metoder

 Konstruktörer

Globala Class-egenskaper

Körningsvariabler

Den globala klassen echosign_dev1.AgreementTemplateVariable har följande två globala fält:

• namn: variabelnamnet, som måste matcha ett körningsvariabelnamn som konfigurerats i avtalsmallen.
• värde: Det variabelvärde som används när mallen läses in. Värdet beror på var variabeln användes. För en mottagare måste det t.ex. vara ett kontakt-, lead- eller användarregistrerings-ID eller ett e-postmeddelande. För en dokumentvariabel måste det vara ett post-ID för en bifogad fil.

Resultat

Varje metod returnerar antingen ID för den nyskapade avtalsposten eller kastar ett undantag med ett detaljerat felmeddelande om något går fel under inläsningen.

API-tjänster

API-malltjänsten Adobe e-Sign visas som en global Apex-tjänst av det hanterade paketet. Detta gör att Apex-kod utanför det hanterade paketet kan anropa en uppsättning API:er för Adobe e-Sign via dessa omslag. Omslagen förenklar API-anropet avsevärt eftersom konsumenterna inte behöver skapa begärande- och svarsdatamodeller. Konsumenterna behöver inte heller hantera omvandlingen av Salesforce-data till e-Sign-datamodeller. Det mesta av komplexiteten tas ifrån konsumenten. Om du t.ex. vill skicka ett avtal som konsumenten just skickar i avtalspost-ID, kommer tjänsten att hantera frågor om det, extrahera alla relevanta data, skicka dem till API för analys av resultatet.

Klassen och alla exponerade metoder markeras som global för att medge sådan tillgång.

• v17 och tidigare anropar SOAP API:er
• v18 och högre anropar REST API:er

Apex-tjänsten visas genom följande anropsklass: echosign_dev1.EchoSignApiService

Apex API-förbättring för alternativa mottagare

Från version 24.14 eller senare gör det uppdaterade Apex API att du kan ersätta eller lägga till alternativa mottagare och är tillgängligt inom den globala klassen "EchoSignApiService", två nya element har införts:

• En global funktion:
  

  /**

  * Indataparametrar:

  * toBeChangedRecipientId: SIGN_Recipient__c Id

  * newRecipientStr: JSON-sträng för SIGN_Recipient__c för en ny mottagare för mottagarersättning eller alternativ

  * changeType: REPLACE eller ALTERNATE

  */

  global static void changeRecipient(Id toBeChangedRecipientId, String newRecipientStr, RECIPIENT_CHANGE_TYPE changeType )

• En global uppräkning: RECIPIENT_CHANGE_TYPE {REPLACE, ALTERNATE}

Exempelkod för att anropa detta API för mottagare (mottagartyp som e-post)

// Fråga först alla mottagare som är kopplade till avtalet

List<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;

// Hitta mottagaren som behöver ersättas eller en alternativ

// I det här fallet hittar du mottagaren via e-post.

// Fler villkor kan läggas till för att hitta mottagaren som ska ersättas eller behöver ett alternativ.

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;

    }

}

// uppdatera ny mottagares e-postadress

newRecipient.echosign_dev1__Email_Address__c = ''someNewUser@abc.com';

// serialisera det till json-sträng

String newRecipientStr = JSON.serialize(newRecipient);

Try {

    echosign_dev1.EchoSignApiService.changeRecipient(replacedRecipient.Id, newRecipientStr, EchoSignApiService.RECIPIENT_CHANGE_TYPE.REPLACE);

} catch (Exception ex) {

    // hantera undantaget och skicka tillbaka vid behov

}

Metoder

Inre klasser

• Global Class: DocumentHistoryEvent

• Global Class: DocumentInfo
  

• Global Class: ParticipantInfo

• Global Class: SendDocumentResult

• Global Class: SigningUrl
  

Apex-grupptjänster

Visar de huvudsakliga e-signeringsavtalsåtgärderna på gruppnivå, vilket gör att en åtgärd kan utföras på en uppsättning avtal. Den här klassen implementerar Salesforce-gränssnittet Database.batchable. Den kan behandla valfritt antal poster, som kommer att delas upp i uppsättningar om 5 och bearbeta varje uppsättning som en enskild transaktion, vilket gör att styrningsgränser respekteras.

Apex-grupptjänsten visas via följande anropsklass: echosign_dev1.EchoSignActionBatch

Parametrar

Du måste ange följande parametrar för att initiera en gruppåtgärd:

• En lista över avtalspost-ID som den angivna åtgärden ska utföras på: Åtgärden kan ha något av följande värden som stöds: Påminn, Skicka, Avbryt, Ta bort eller Uppdatera.
• Aktuellt användarsessions-ID: Krävs endast för en uppdateringsåtgärdstyp.
• Skickarens användarpost: Används för att meddela användaren via e-post när bulkbearbetningen har slutförts.

Användningsexempel

User submitterUser = UserInfo.getUserId();

EchoSignActionBatch batch = new EchoSignActionBatch( agreementIds, 'Remind', UserInfo.getSessionId(), submitterUser); Id syncProcessId = Database.executeBatch(batch, 5); 

Mallgrupp för avtal

Tar in en SOQL-fråga och ett post-ID för avtalsmallen. Frågan körs för att hämta en uppsättning huvudobjektsposter, som sedan körs via den angivna avtalsmallen för att generera en avtalspost. Den här klassen implementerar Salesforce-gränssnittet Database.batchable. Den kan behandla valfritt antal poster, som kommer att delas upp i uppsättningar om 5 och bearbeta varje uppsättning som en enskild transaktion, vilket gör att styrningsgränser respekteras.

De posttyper som returneras av SOQL-frågan måste matcha den angivna huvudobjekttypen för avtalsmallen. För varje post anropas avtalsmalltjänsten.

Apex-grupptjänsten visas via följande anropsklass:

echosign_dev1.AgreementTemplateBatch

Parametrar

Du måste ange följande parametrar för att initiera en gruppåtgärd:

• SOQL-fråga att köra: Den måste innehålla post-ID som ett valt fält. Övriga fält är valfria.
• Post-ID för avtalsmall: Används tillsammans med huvudpost-ID för att ladda ett avtal.

Användningsexempel

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);

Tjänstgrupp för avtalsmall

Tar in en lista över huvudobjektspost-ID och huvudobjekttyp, som sedan efterfrågas, och som sedan körs genom den angivna avtalsmallen för att generera en avtalspost. Den här klassen implementerar Salesforce-gränssnittet Database.batchable. Den kan behandla valfritt antal poster, som kommer att delas upp i uppsättningar om 5 och bearbeta varje uppsättning som en enskild transaktion, vilket gör att styrningsgränser respekteras.

Den angivna huvudobjekttypen måste matcha den angivna huvudobjekttypen för avtalsmallen. För varje post anropas avtalsmalltjänsten.

Apex-grupptjänsten visas via följande anropsklass:

echosign_dev1.AgreementTemplateServiceBatch

Parametrar

Du måste ange följande parametrar för att initiera en gruppåtgärd:

• Lista över ID för huvudposter.
• Avtalsmallens post-ID: Används tillsammans med huvudposterna för att ladda ett avtal.
• Huvudobjektnamn som ska efterfrågas för huvudposterna.

Användningsexempel

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);

REST-tjänster

Avtalsmalltjänst

Avtalsmalltjänsten visas som en Salesforce REST-webbtjänst av det hanterade paketet. Detta gör att externa system utanför Salesforce-organisationen kan läsa in avtal som baseras på befintliga avtalsmallar. Se artikeln Skapa REST API:er med Apex REST för mer information om hur du får åtkomst till och anropar anpassade REST Apex-tjänster inifrån Salesforce. Anrop måste innehålla ett giltigt sessions-ID för autentisering och auktorisering.

Webbtjänsten visas från följande URL:

https://<instance_name>.salesforce.com/services/apexrest/echosign_dev1/template/load/<template_id>?masterId=<master_id>&varName1=var Value1&varName2=varValue2

Mall-ID

Den sista delen av URL:en är ID:t för avtalsmallposten i den aktuella Salesforce-organisationen som ska användas för att läsa in avtalet. Den här delen av URL:en är valfri. Om den utelämnas läses avtalsmallen som är markerad som standard in. Om mall-ID:t utelämnas och det inte finns något standardavtalsmall-ID returneras ett fel.

Mall-ID:t kan vara i formatet med 15 eller 18 tecken.

Master ID

Parametern masterId anger vilken huvudpost som ska användas för att läsa in avtalet från den specifika avtalsmallen. Den här parametern är valfri, men måste anges för alla avtalsmallar som anger en huvudobjekttyp och refererar till huvudobjektet i mallen.

Master-ID:t kan vara i formatet med 15 eller 18 tecken.

Körningsvariabler

Eventuella ytterligare parametrar används som körningsvariabler, som namnvärdepar, som används för att fylla i eventuella körningsvariabler som anges i avtalsmallen.

Resultat

REST-webbtjänsten returnerar ett LoadResult-objekt som innehåller följande fält:

• agreementId: om inläsningen av avtalet lyckades innehåller detta ID:t för den nyligen skapade avtalsposten.
• fel: om det uppstod något fel när avtalet lästes in, innehåller det här fältet ett detaljerat felmeddelande.

Bakgrundstjänst

Bakgrundstjänstens kapacitet gör att paketanvändare kan anropa olika åtgärder på ett avtalsobjekt genom att uppdatera fältet Bakgrundsåtgärd (echosign_dev1 Background_Actions c) till motsvarande värde. När fältvärdet har ändrats från ett tomt värde eller ett annat värde till ett av följande värden, utförs åtgärden från en utlösare som ingår i det e-Sign-hanterade paketet.

• Påminn
• Skicka
• Avbryt
• Ta bort
• Uppdatera

Alla åtgärder körs i ett asynkront framtida läge, så statusen lagras i fältet Fel i avtalet.

Ändringar av bakåtkompatibilitet