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

Adobe Acrobat Sign för Salesforce: användarhandbok för utvecklare är utformad för att hjälpa Salesforce-utvecklare att lära sig mer om de objekt och parametrar som krävs för att integrera Salesforce-paketet med Adobe Acrobat Sign.

• 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"

Uppdatera order

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 har alla asynkrona processer (som inkluderar automatiska uppdateringar och datamappningar) växlats från framtida metoder till köbara, vilket rekommenderas av Salesforce.

Med denna ändring kommer alla anpassningar i den prenumererande organisationen som lägger till jobb i Salesforce-kön som en del av den automatiska uppdateringen eller datamappningsprocessen misslyckas med ett fel "System.LimitException: för många köbara jobb har lagts till i kön: 2".

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

Fel: "När jobb länkas kan du bara lägga till ett jobb från ett jobb som körs med System.enqueueJob, vilket innebär att endast ett underordnat jobb kan existera för varje överordnat köande jobb. Att starta flera underordnade jobb från samma köbara jobb stöds inte."

Ovanstående fel uppstår när avtalsstatusen inte ändras eller datamappningen inte körs korrekt. Åtgärda felet genom att leta efter utlösaren, processbyggaren eller arbetsflödet som orsakar problemet och inaktivera den, ändra den till synkrona anrop eller schemalägga den för 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 genom följande anropsklass: echosign_dev1.AgreementTemplateService

  Metoder

 Konstruktörer (1)

global class AgreementTemplateService.AgreementTemplateListOptions

Egenskaper (5)

global class AgreementTemplateService.AgreementTemplateBasicInfo

Egenskaper (6)

global class AgreementTemplateService.AgreementTemplateDetails

Egenskaper (6)

global class AgreementTemplateService.RecipientInfo

Egenskaper (4)

  Körningsvariabler

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

• namn: variabelnamnet, som måste matcha ett körningsvariabelnamn som konfigurerats i avtalsmallen.
• värde: värdet på den variabel som ska användas när mallen läses in. Värdet beror på var variabeln användes. För en mottagare måste det till exempel vara ett kontakt-, lead- eller användarpost-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 nyligen skapade avtalsposten eller genererar ett undantag med ett detaljerat felmeddelande om något gick fel under inläsningen.

API-tjänst

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

Metoder

Inre klasser

global class DocumentHistoryEvent

Egenskaper (2)

Konstruktörer (1)

global class DocumentInfo

Egenskaper (5)

  Konstruktörer (1)

global class ParticipantInfo

Egenskaper (5)

  Konstruktörer (1)

global class SendDocumentResult

Egenskaper (3)

Konstruktörer (1)

global class SigningUrl

Egenskaper (3)

Konstruktörer (1)

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

Följande parametrar måste anges för att initiera en gruppåtgärd.

En lista över avtalspost-ID som den angivna åtgärden ska utföras på. Åtgärden som ska utföras, ett av följande värden som stöds:

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

Aktuellt användarsessions-ID. Krävs endast för en uppdateringsåtgärdstyp.

Uppgiftslämnarens användarpost, som används för att meddela användaren via ett e-postmeddelande när gruppbearbetningen har slutförts.

Användningsexempel

User submitterUser = UserInfo.getUserId();

EchoSignActionBatch batch = new EchoSignActionBatch( agreementIds, 'Remind', UserInfo.getSessionId(), submitterUser); 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

Följande parametrar måste anges för att initiera en gruppåtgärd.

SOQL-fråga som ska köras måste innehålla post-ID som ett valt fält. Alla andra fält är valfria.

Post-ID för avtalsmall som används i samband med huvudpost-ID för att läsa in 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); 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

Följande parametrar måste anges för att initiera en gruppåtgärd.

• Lista över huvudpost-ID.
• Post-ID för avtalsmall som används i samband med huvudposterna för att läsa in 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');
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