Adobe Acrobat Sign for Salesforce - Udviklerhåndbog

Adobe Acrobat Sign for Salesforce: Udviklerhåndbog er designet til at hjælpe Salesforce-udviklere med at lære om de objekter og parametre, der er påkrævede for integration af din Salesforce-pakke med Adobe Acrobat Sign.

Se emnerne nedenfor for at få mere at vide om:

• Retningslinjer for udviklere
• Opdater ordre
• Apex-tjenester
• API-tjenester
• Apex Batch-tjenester
• Aftaleskabelonbatch
• Tjenesteaftaleskabelonbatch
• REST-tjenester
• Baggrundstjenester
• Ændringer ift. bagudkompatibilitet

• Hvis du har brug for at vide, hvornår aftalen er fuldt underskrevet, skal du implementere en Apex-udløser på objektet echosign_dev1 __ SIGN_Agreement__c, efter eller før opdatering (afhængigt af brugstilfælde og krav). Når feltet echosign_dev1 __Status__c ændres til Underskrevet eller Godkendt eller anden endelig status, udfyldes aftalen. 
• Hvis du vil vide, hvornår hver enkelt underskrevet PDF er indsat, hvis du for eksempel har brug for at få hver mellemliggende underskrevet PDF, så implementere en Apex trigger på Vedhæftet fil eller ContentVersion objekter, efter indsættelse, og se efter en overordnet aftale og et navn, der ender på "- signed.pdf" eller "- approved.pdf" eller anden endelig status
• Hvis du vil vide, hvornår en individuel modtager har underskrevet eller godkendt, skal du implementere en Apex-udløser på objektet echosign_dev1 __ SIGN_Recipients __c efter eller før opdatering (afhængigt af brugstilfælde og krav). Når echosign_dev1 __ Status__c feltet ændres Underskrevet eller Godkendt eller andre endelige statusser, er modtageren fuldført.  
• Hvis du har brug for at vide, hvornår en bestemt event, der er en del af underskrivelsesprocessen, finder sted, f.eks. en aftale, der sendes til underskrivelse, eller en påmindelse, der sendes, kan der oprettes en udløser på aftalens begivenhedsobjekt (echosign_dev1__SIGN_AgreementEvent__c) og kontrolleres for begivenhedens type
• De endelige aftalestatusnavne for en afsluttet aftale er: "Underskrevet", "Godkendt", "Accepteret", "Formular-udfyldt" og "Leveret"
  
• De endelige aftalestatusnavne for en opsagt aftale er: "Annulleret/afvist ", "Annulleret/afvist", "Udløbet"

Rækkefølge af opdateringer

I v21 har rækkefølgen af opdateringer ændret sig. Nedenfor er sekvensen, hvori aftalen og dens relaterede objekter opdateres:

1. Vedhæftede filer 
2. Modtagere 
3. Aftale (status og dens andre attributter)
4. Aftalehændelser 
5. Chatter-feeds 

Apex-tjenester

Apex-metode i brug

Når Acrobat Sign startes for Salesforce v 21.0, bruger alle asynkrone processer (inklusive automatiske opdateringer og datatilknytninger) metoden Queueable i stedet for Future, som Salesforce anbefaler.
Med denne ændring vil alle tilpasningsjob, der føjes til Salesforce-køen til automatisk opdatering eller datatilknytning, mislykkes med denne fejl: "System.LimitException: For mange køaktiverede job føjet til køen:2."

Fejlen opstår, fordi en proces, der kan sættes i kø, kun kan tilføje ét underordnet job, der kan sættes i kø, og som allerede udføres af Acrobat Sign. For yderligere oplysninger, se Køaktiverede Apex-grænser.

Når aftalestatussen ikke ændres, eller datatilknytningen ikke kører korrekt, kan den vise denne fejl: "Når job sættes i kæde, kan du kun tilføje ét job fra et job under udførelse med System.enqueueJob, hvilket betyder, at der kun kan findes ét underordnet job for hvert overordnede køaktiverede job. Start af flere underordnede job fra det samme køaktiverede job understøttes ikke."

For at løse denne fejl skal du søge efter den/det problematiske udløser, proceseditor eller arbejdsforløb og deaktivere den eller det eller skifte den eller det til at bruge et synkront kald eller udskyde tidspunktet.

Tjeneste til aftaleskabeloner

Aftaleskabelontjenesten afsløres som en global Apex-tjeneste af den administrerede pakke. Dette gør det muligt for Apex-kode uden for den administrerede pakke at indlæse aftaler baseret på eksisterende aftaleskabeloner. Klassen og alle eksponerede metoder er markeret som globale for at tillade en sådan adgang.

Apex-tjenesten eksponeres gennem følgende påkaldelsesklasse: echosign_dev1.AgreementTemplateService

Metoder

 Konstruktører

Globale klasseegenskaber

Kørselsvariabler

Den globale klasse echosign_dev1.AgreementTemplateVariable har to globale felter:

• name: Variabelnavnet, som skal matche et kørselsvariabelnavn, der er konfigureret i aftaleskabelonen.
• værdi: Den variabelværdi, der bruges under indlæsning af skabelonen. Værdien afhænger af, hvor variablen blev brugt. For en modtager skal det f.eks. være en kontakt, et salgsemne, et brugerpost-id eller en mail. For en dokumentvariabel skal det være en bilagspost-id.

Resultat

Hver metode returnerer enten id'et for den nyoprettede aftalepost eller smider en undtagelse med en detaljeret fejlmeddelelse, hvis noget gik galt under indlæsningen.

API-tjenester

Skabelontjenesten Adobe e-Sign API udsættes som en global Apex-tjeneste af den administrerede pakke. Dette gør det muligt for Apex-kode uden for den administrerede pakke at påberåbe sig et sæt Adobe e-Sign API'er gennem disse wrappers. Wrappers forenkler i høj grad API påkaldelse, fordi forbrugerne ikke behøver at oprette anmodning og svar datamodel. Det er heller ikke nødvendigt, at forbrugerne håndterer omdannelsen af Salesforce-data til e-sign-datamodeller. Størstedelen af kompleksiteten er hentet fra forbrugeren. For eksempel, for at sende en aftale forbrugeren bare passerer i aftalen post ID, tjenesten vil håndtere forespørgsel det, udtrække alle de relevante data, videregive det på API og parsing resultatet.

Klassen og alle eksponerede metoder er markeret som globale for at tillade en sådan adgang.

• v17 og derunder påberåber sig SOAP API'er
• v18 og derover påberåber REST-API'er

Apex-tjenesten eksponeres gennem følgende påkaldelsesklasse: echosign_dev1.EchoSignApiService

Apex API-forbedring for alternative modtagere

Fra og med version 24.14 eller nyere giver den opdaterede Apex API dig mulighed for at udskifte eller tilføje alternative modtagere, og den er tilgængelig i den globale klasse "EchoSignApiService" – der er introduceret to nye elementer:

• En global funktion:
  

  /**

  * Inputparametre:

  * toBeChangedRecipientId: SIGN_Recipient__c Id

  * newRecipientStr: JSON-streng af SIGN_Recipient__c for en ny modtager til modtagerudskiftning eller -alternativ

  * changeType: REPLACE eller ALTERNATE

  */

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

• En global optælling: RECIPIENT_CHANGE_TYPE {REPLACE, ALTERNATE}

Prøvekode til at kalde denne API for modtagere (modtagertype som mail)

// først forespørge alle de modtagere, der er tilknyttet aftalen

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

// find den modtager, der skal udskiftes, eller en alternativ modtager

// i dette tilfælde skal du finde modtageren via dennes mail.

// Flere betingelser kan tilføjes for at finde den modtager, der skal udskiftes eller skal bruge en alternativ modtager.

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;

    }

}

// opdater mailadressen til den nye modtager

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

// serialiser den til json-streng

String newRecipientStr = JSON.serialize(newRecipient);

Prøv {

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

} catch (undtagelse ex) {

    // håndterer undtagelsen og gengiver den om nødvendigt

}

Metoder

Indre klasser

• Global klasse: DocumentHistoryEvent

• Global klasse: DocumentInfo
  

• Global klasse: ParticipantInfo

• Global klasse: SendDocumentResult

• Global klasse: SigningUrl
  

Apex Batch-tjenester

Afslører de vigtigste foranstaltninger i forbindelse med e-signeringsaftaler på bulkplan, hvilket gør det muligt at gennemføre en operation på grundlag af en række aftaler. Denne klasse implementerer Salesforce Database.Batchable interface. Det kan behandle et vilkårligt antal poster, som vil blive opdelt i sæt på 5 og behandle hvert sæt som en individuel transaktion, som gør det muligt at overholde centralbankchefens grænser.

Apex batch-tjenesten eksponeres gennem følgende påkaldelsesklasse: echosign_dev1.EchoSignActionBatch

Parametre

Du skal angive følgende parametre for at initialisere en batchhandling:

• En liste over de aftalepost-id'er, som den angivne handling skal udføres på: Handlingen kan have en af følgende understøttede værdier: Påmind, Send, Annuller, Slet eller Opdater.
• Id for aktuel brugersession: Kræves kun for en opdateringshandlingstype.
• Indsenders brugerpost: Bruges til at underrette denne bruger via en mail, når massebehandlingen er afsluttet.

Eksempel på anvendelse

User submitterUser = UserInfo.getUserId();

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

Aftaleskabelonbatch

Tager en SOQL-forespørgsel og et aftaleskabelonpost-id. Forespørgslen udføres for at få et sæt masterobjektposter, som hver derefter køres gennem den medfølgende aftaleskabelon for at generere en aftalepost. Denne klasse implementerer Salesforce Database.Batchable interface. Det kan behandle et vilkårligt antal poster, som vil blive opdelt i sæt på 5 og behandle hvert sæt som en individuel transaktion, som gør det muligt at overholde centralbankchefens grænser.

De posttyper, der returneres af SOQL-forespørgslen, skal matche den angivne aftaleskabelon for hovedobjekttypen. For hver post påberåbes aftaleskabelontjenesten.

Apex batch service eksponeres gennem følgende påkaldelsesklasse:

echosign_dev1.AgreementTemplateBatch

Parametre

Du skal angive følgende parametre for at initialisere en batchhandling:

• SOQL-forespørgsel: Den skal indeholde post-id som et valgt felt. Andre felter er valgfrie.
• Aftaleskabelonens post-id: Det vil blive brugt sammen med master post-id til at indlæse en aftale.

Eksempel på anvendelse

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

Tjenesteaftaleskabelonbatch

Indsætter en liste over master-objektpost-id'er og master-objekttypen, som dernæst forespørges, og som dernæst køres gennem den medfølgende aftaleskabelon for at generere en aftalepost. Denne klasse implementerer Salesforce Database.Batchable interface. Det kan behandle et vilkårligt antal poster, som vil blive opdelt i sæt på 5 og behandle hvert sæt som en individuel transaktion, som gør det muligt at overholde centralbankchefens grænser.

Den angivne hovedobjekttype skal matche den angivne aftaleskabelon for master objekttypen. For hver post påberåbes aftaleskabelontjenesten.

Apex batch service eksponeres gennem følgende påkaldelsesklasse:

echosign_dev1.AgreementTemplateServiceBatch

Parametre

Du skal angive følgende parametre for at initialisere en batchhandling:

• Liste over master post-id'er.
• Aftaleskabelonens post-id: Det vil blive brugt sammen med masterposter til at indlæse en aftale.
• Master objektnavn til forespørgsel efter master poster.

Eksempel på anvendelse

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-tjenester

Tjeneste til aftaleskabeloner

Aftaleskabelontjenesten er eksponeret som en Salesforce REST-webtjeneste af den administrerede pakke. Dette gør det muligt for eksterne systemer uden for Salesforce-organisationen at indlæse aftaler baseret på eksisterende aftaleskabeloner. Se artiklen Oprettelse af REST API'er ved hjælp af Apex REST for at få flere oplysninger om, hvordan du får adgang til og kan påberåbe brugerdefineret REST Apex-tjenester fra Salesforce. Invitationer skal angive et gyldigt sessions-id for godkendelse og autorisation.

Webtjenesten eksponeres fra følgende URL-adresse:

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

Skabelon-ID

Den sidste del af webadressen er id'et for aftaleskabelonposten i den aktuelle Salesforce-organisation, som skal bruges til at indlæse aftalen. Denne del af webadressen er valgfri. Hvis udeladt, vil aftaleskabelonen markeret som standard blive indlæst. Hvis skabelon-id'et udelades, og der ikke findes nogen standard aftaleskabelon-id, returneres en fejl.

Skabelon-id kan være i 15 eller 18 tegn format.

Master-id

Master-Id-parameteren angiver, hvilken master post der skal bruges til at indlæse aftalen fra den specifikke aftaleskabelon. Denne parameter er valgfri, men skal angives for en aftaleskabelon, der angiver en master objekttype og refererer til det master objekt i skabelonen.

Master-id kan være i 15 eller 18 tegn format.

Kørselsvariabler

Eventuelle yderligere parametre bruges som kørselsvariabler, som navne-værdipar, der bruges til at udfylde eventuelle kørselsvariabler angivet i aftaleskabelonen.

Resultat

REST-webservicen returnerer et LoadResult-objekt, som indeholder følgende felter:

• agreementId: Hvis indlæsningen af aftalen var vellykket, indeholder dette id'et for den nyoprettede aftale-post.
• fejl: Hvis der opstod en fejl under indlæsningen af aftalen, vil dette felt indeholde en detaljeret fejlmeddelelse.

Baggrundstjeneste

Baggrundstjenesten giver pakkemodtagere mulighed for at udføre forskellige handlinger på et aftaleobjekt ved at opdatere feltet Baggrundshandling (echosign_dev1 Background_Actions c) til den tilsvarende værdi. Når feltværdien er ændret fra en tom værdi - eller en anden værdi - til en af følgende værdier, startes handlingen via en udløser, som er en del af den e-Sign-administrerede pakke.

• Påmind
• Send
• Annuller
• Slet
• Opdater

Alle handlingerne udføres i "asynchronous future mode", så status gemmes i feltet Fejl på aftalen.

Ændringer ift. bagudkompatibilitet