Adobe Acrobat Sign for Salesforce: Utviklerveiledning

Adobe Acrobat Sign for Salesforce: Utviklerveiledningen er utformet for å hjelpe Salesforce-utviklere, slik at de kan lære om objektene og parametrene som kreves for å integrere Salesforce-pakken med Adobe Acrobat Sign.

Se emnene i dette dokumentet for å finne ut mer om:

• Utviklerveiledninger
• Oppdateringsrekkefølge
• Apex-tjenester
• API-tjenester
• Apex-batchtjenester
• Avtalemalbatch
• Avtalemaltjenestebatch
• REST-tjenester
• Bakgrunnstjenester
• Endringer i bakoverkompatibilitet

• Hvis du trenger å vite når avtalen er fullstendig signert, implementerer du en Apex-utløser på objektet echosign_dev1__SIGN_Agreement__c, etter eller før oppdatering (avhengig av brukstilfelle og krav). Når echosign_dev1__Status__c-feltet endres til Signert eller Godkjent eller andre endelige statuser, er avtalen fullført. 
• Hvis du vil vite når hver enkelt signert PDF-fil settes inn, hvis du for eksempel trenger hver mellomliggende signert PDF-fil, må du implementere en Apex-utløser på vedleggs- eller innholdsversjonsobjektene, etter innsetting, og se etter en overordnet avtale og et navn som slutter på «- signed.pdf» eller «- approved.pdf» eller en annen endelig status
• Hvis du trenger å vite når en individuell mottaker har signert eller godkjent, implementerer du en Apex-utløser på echosign_dev1__SIGN_Recipients __ c-objektet, etter eller før oppdatering (avhengig av brukstilfelle og krav). Når echosign_dev1__Status__c-feltet endrer Signert eller Godkjent eller andre endelige statuser, er mottakeren fullført.  
• Hvis du trenger å vite når en bestemt hendelse som er en del av signeringsprosessen, for eksempel en avtale som sendes for signering eller en påminnelse som sendes, kan en utløser opprettes på avtalehendelsesobjektet (echosign_dev1__SIGN_AgreementEvent __c) og se etter hendelsestypen
• De endelige avtalestatusnavnene for en fullført avtale er: «Signert», «Godkjent», «Akseptert», «Skjema fylt» og «Levert»
  
• De endelige avtalestatusnavnene for en avsluttet avtale er: «Avbrutt / avslått», «Avbrutt / avslått», «Utløpt»

Oppdateringsrekkefølge

I v21 er oppdateringsrekkefølgen endret. Nedenfor er sekvensen som avtalen og dens relaterte objekter oppdateres etter:

1. Vedlegg 
2. Mottakere 
3. Avtale (status og dens andre attributter)
4. Avtalehendelser 
5. Chatter-feeder 

Apex-tjenester

Apex-metode i bruk

Starter Acrobat Sign for Salesforce v21.0, bruker alle asynkrone prosesser (inkludert automatiske oppdateringer og datatilordninger) køleggingsmetoden fremfor Future-metoden, som anbefalt av Salesforce.
Med denne endringen vil alle tilpasningsjobber som legges til i Salesforce-køen for automatisk oppdatering eller datatilordning, mislykkes og få denne feilen: «System.LimitException: For mange køjobber lagt til i kø:2.»

Feilen oppstår fordi en prosess som kan settes i kø bare kan legge til én underordnet kø-jobb, som allerede er tatt opp av Acrobat Sign. For detaljer, se købare Apex-grenser.

Når avtalestatusen ikke endres eller datatilordningen ikke kjører riktig, kan den vise denne feilen: «Ved kjeding av jobber kan du bare legge til én jobb fra en kjørende jobb med System.enqueueJob, som betyr at bare én underordnet jobb kan finnes for hver overordnede køjobb. Det er ikke støtte for å starte flere underordnede jobber fra samme køjobb.»

For å rette denne feilen må du se etter den problematiske utløseren, prosessbyggeren eller arbeidsflyten, og deaktivere den eller endre den til å bruke et synkront kall eller planlegge den for senere kjøring.

Avtalemaltjeneste

Avtalemaltjenesten eksponeres som en global Apex-tjeneste av den administrerte pakken. Dette tillater Apex-kode utenfor den administrerte pakken å laste inn avtaler basert på eksisterende avtalemaler. Klassen og alle eksponerte metoder er merket som globale for å tillate slik tilgang.

Apex-tjenesten er eksponert via denne invokasjonsklassen: echosign_dev1.AgreementTemplateService

Metoder

 Konstruktører

Egenskaper for global klasse

Kjøretidsvariabler

Den globale klassen echosign_dev1.AgreementTemplateVariable har to globale felt:

• navn: Variabelnavnet, som må samsvare med et navn på kjøretidsvariabel konfigurert i avtalemalen.
• verdi: Variabelverdien som brukes under malinnlastingen. Verdien avhenger av hvor variabelen ble brukt. For en mottaker må det for eksempel være en kontakt-, salgsemne- eller brukerpost-ID eller en e-post. For en dokumentvariabel må den være en vedleggspost-ID.

Resultat

Hver metode returnerer enten ID for den nyopprettede avtaleposten eller utløser et unntak med en detaljert feilmelding hvis noe gikk galt under lasteoperasjonen.

API-tjenester

Adobe e-Sign API-maltjenesten eksponeres som en global Apex-tjeneste av den administrerte pakken. Dette gjør det mulig for Apex-kode utenfor den administrerte pakken å starte et sett med Adobe e-Sign API-er gjennom disse pakkerene. Pakkerene forenkler i stor grad API-kallet fordi forbrukerne ikke trenger å opprette forespørsels- og svardatamodell. Det er heller ikke nødvendig for forbrukerne å håndtere transformasjonen av Salesforce-data til e-Sign-datamodeller. Det meste av kompleksiteten er hentet fra forbrukeren. For å sende en avtale som forbrukeren bare sender videre i avtaleoppføring-ID-en, vil tjenesten for eksempel håndtere spørring, trekke ut alle relevante data, sende det videre til API-en og analysere resultatet.

Klassen og alle eksponerte metoder er merket som globale for å tillate slik tilgang.

• v17 og under starter SOAP-API-er
• v18 og over starter REST API-er

Apex-tjenesten eksponeres gjennom følgende påkallelsesklasse: echosign_dev1.EchoSignApiService

Apex API-forbedring for alternative mottakere

Fra versjon 24.14 eller nyere, lar den oppdaterte Apex API deg erstatte eller legge til alternative mottakere og er tilgjengelig innenfor den globale klassen «EchoSignApiService», to nye elementer har blitt introdusert:

• En global funksjon:
  

  /**

  * Inndataparametere:

  * toBeChangedRecipientId: SIGN_Recipient__c Id

  * newRecipientStr: JSON-streng av SIGN_Recipient__c for en ny mottaker for erstatning av mottaker eller alternativ

  * changeType: REPLACE eller ALTERNATE

  */

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

• En global opplisting: RECIPIENT_CHANGE_TYPE {REPLACE, ALTERNATE}

Eksempelkode for å kalle dette API-et for mottakere (mottakertype som e-post)

// spør først alle mottakerne som er knyttet til avtalen

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;

// finn mottakeren som må erstattes eller et alternativ

// i dette tilfellet finner du mottakeren via e-post.

// Du kan legge til flere betingelser for å finne mottakeren som skal erstattes, eller som trenger et 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;

    }

}

// oppdater e-postadresse for ny mottaker

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

// serialiser til json-streng

Streng newRecipientStr = JSON.serialize(newRecipient);

Prøv {

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

} catch (Unntak eks) {

    // håndtere unntaket og endre om nødvendig

}

Metoder

Innerklasser

• Global klasse: DocumentHistoryEvent

• Global klasse: DocumentInfo
  

• Global klasse: ParticipantInfo

• Global klasse: SendDocumentResult

• Global klasse: SigningUrl
  

Apex-batchtjenester

Avslører de viktigste tiltakene i e-signeringsavtalen på massenivå, slik at en operasjon kan utføres på et sett med avtaler. Denne klassen implementerer Salesforce Database.Batchable -grensesnittet. Det kan behandle et hvilket som helst antall oppføringer, som vil bli brutt ned i sett på 5, og behandle hvert sett som en individuell transaksjon, som gjør det mulig å respektere regulatorgrensene.

Apex-gruppetjenesten eksponeres gjennom følgende påkallelsesklasse: echosign_dev1.EchoSignActionBatch

Parametere

Du må angi følgende parametere for å initialisere en satsvis operasjon:

• En liste over ID-ene for avtaleoppføringen der den angitte handlingen skal utføres: Handlingen kan ha en av følgende støttede verdier: påminn, send, avbryt, slett eller oppdater.
• Gjeldende brukerøkt-ID: Bare nødvendig for en oppdateringshandlingstype.
• Innsenders brukeroppføring: Brukes til å varsle denne brukeren via en e-post når massebehandlingen er fullført.

Brukseksempel

User submitterUser = UserInfo.getUserId();

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

Avtalemalbatch

Tar inn en SOQL-spørring og en avtalemalpost-ID. Spørringen utføres for å få et sett med hovedobjektoppføringer, som hver deretter kjøres gjennom den medfølgende avtalemalen for å generere en avtaleoppføring. Denne klassen implementerer Salesforce Database.Batchable-grensesnittet. Det kan behandle et hvilket som helst antall oppføringer, som vil bli brutt ned i sett på 5, og behandle hvert sett som en individuell transaksjon, som gjør det mulig å respektere regulatorgrensene.

Posttypene som returneres av SOQL-spørringen, må samsvare med den angitte hovedkontotype for avtalemal. For hver post blir avtalemalen for tjenesten påkalt.

Apex batch-tjenesten eksponeres gjennom følgende påkallelsesklasse:

echosign_dev1.AgreementTemplateBatch

Parametere

Du må angi følgende parametere for å initialisere en satsvis operasjon:

• SOQL-spørring som skal utføres: Den må inneholde oppførings-ID-en som et valgt felt. Andre felt er valgfrie.
• Avtalemalens oppførings-ID: Brukes med hovedoppførings-ID for å laste inn en avtale.

Brukseksempel

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

Avtalemaltjenestebatch

Tar inn en liste over hovedobjektoppføring-ID-er og hovedobjekttypen, som deretter spørres og som så kjøres gjennom den medfølgende avtalemalen for å generere en avtalepost. Denne klassen implementerer Salesforce Database.Batchable-grensesnitt. Det kan behandle et hvilket som helst antall oppføringer, som vil bli brutt ned i sett på 5, og behandle hvert sett som en individuell transaksjon, som gjør det mulig å respektere regulatorgrensene.

Den angitte hovedobjekttypen må samsvare med den angitte avtalemalen for hovedobjekttype. For hver post blir avtalemalen for tjenesten påkalt.

Apex batch-tjenesten eksponeres gjennom følgende påkallelsesklasse:

echosign_dev1.AgreementTemplateServiceBatch

Parametere

Du må angi følgende parametere for å initialisere en satsvis operasjon:

• Liste over hovedoppførings-ID-er.
• Avtalemaloppførings-ID: Brukes med hovedoppføringene for å laste inn en avtale.
• Navnet på hovedobjektet som skal spørres etter hovedpostene.

Brukseksempel

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

Avtalemaltjeneste

Avtalemaltjenesten eksponeres som en Salesforce REST-webtjeneste av den administrerte pakken. Dette gjør det mulig for eksterne systemer utenfor Salesforce-organisasjonen å laste inn avtaler basert på eksisterende avtalemaler. Se artikkelen Opprette REST API-er ved hjelp av Apex REST for mer informasjon om hvordan du får tilgang til og bruker tilpassede REST Apex-tjenester fra Salesforce. Det må oppgis en gyldig økt-ID for godkjenning og autorisasjon.

Webtjenesten eksponeres fra følgende nettadresse:

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

Mal-ID

Den siste delen av nettadressen er ID-en til avtalemalposten i gjeldende Salesforce-organisasjon, som skal brukes til å laste inn avtalen. Denne delen av nettadressen er valgfri. Hvis utelatt, vil avtalemalen merket som standard bli lastet inn. Hvis mal-ID-en utelates og det ikke finnes noen standard avtalemal-ID, returneres en feil.

Mal-ID-en kan være i format på 15 eller 18 tegn.

Hoved-ID

Hoved-ID-parameteren angir hvilken hovedpost som skal brukes til å laste avtalen fra den spesifikke avtalemalen. Denne parameteren er valgfri, men må angis for en avtalemal som angir en overordnet objekttype og refererer til dette overordnede objektet i malen.

Hoved-ID-en kan være i format på 15 eller 18 tegn.

Kjøretidsvariabler

Eventuelle tilleggsparametere brukes som kjøretidsvariabler, som navneverdipar, brukes til å fylle ut eventuelle kjøretidsvariabler angitt i avtalemalen.

Resultat

REST-webtjenesten returnerer et LoadResult-objekt som inneholder følgende felt:

• agreementId: Hvis avtaleinnlastingsoperasjonen var vellykket, inneholder denne ID-en til den nyopprettede avtaleposten.
• feil: Hvis det var noen feil under lasting av avtalen, vil dette feltet inneholde en detaljert feilmelding.

Bakgrunnstjeneste

Funksjonen Bakgrunnstjeneste gjør det mulig for pakkeforbrukere å påberope seg ulike handlinger på et avtaleobjekt ved å oppdatere feltet Bakgrunnshandling (echosign_dev1 Background_Actions c) til tilsvarende verdi. Når feltverdien er endret fra en tom verdi eller en annen verdi til én av følgende verdier, blir handlingen startet fra en utløser som er en del av den e-Sign-administrerte pakken.

• Påminn
• Send
• Avbryt
• Slett
• Oppdater

Alle handlingene utføres i en asynkron fremtidig modus, slik at statusen vil bli lagret i Feil-feltet i avtalen.

Endringer i bakoverkompatibilitet