사용 안내서 취소

webhook 구성

검색

마지막 업데이트 날짜 2024년 1월 10일 | 다음에도 적용됨 Adobe Acrobat Sign

Adobe Sign

앱 열기

Adobe Acrobat Sign 통합
새로운 기능
제품 버전 및 수명 주기
Salesforce용 Acrobat Sign
Microsoft용 Acrobat Sign
1. Microsoft 365용 Acrobat Sign
  1. 설치 안내서
2. Outlook용 Acrobat Sign
  1. 사용 안내서
3. Word/PowerPoint용 Acrobat Sign
  1. 사용 안내서
4. Teams용 Acrobat Sign
5. Microsoft PowerApps 및 Power Automate용 Acrobat Sign
  1. 사용 안내서
  2. 릴리스 정보
6. Microsoft Search용 Acrobat Sign 커넥터
  1. 사용 안내서
  2. 릴리스 정보
7. Microsoft Dynamics용 Acrobat Sign
8. Microsoft SharePoint용 Acrobat Sign
ServiceNow용 Acrobat Sign
HR ServiceNow용 Acrobat Sign
1. 설치 안내서(사용 종료)
SAP SuccessFactors용 Acrobat Sign
Workday용 Acrobat Sign
NetSuite용 Acrobat Sign
1. 설치 안내서
2. 릴리스 정보
SugarCRM용 Acrobat Sign
VeevaVault용 Acrobat Sign
Coupa BSM Suite용 Acrobat Sign
1. 설치 안내서
Zapier용 Acrobat Sign
Acrobat Sign 개발자 설명서

개요

Webhook은 소스 사이트(이 경우 Adobe Acrobat Sign)에서 구독 이벤트가 발생할 때 트리거되는 사용자 지정된 HTTPS 요청입니다.

사실상 Webhook은 데이터 또는 데이터 스트림을 수락하는 REST 서비스에 불과합니다.

Webhook은 푸시 모델에서 서비스 간 통신을 위한 것입니다.

구독 이벤트가 트리거되면 Acrobat Sign은 JSON 본문을 사용하여 HTTPS POST를 구성하고 지정된 URL로 전달합니다.

Webhook은 이전 콜백 방법에 비해 여러 가지 이점을 제공하며, 그중 일부는 다음과 같습니다.

관리자는 콜백 URL을 나열하기 위해 Acrobat Sign 지원을 사용할 필요 없이 Webhook을 활성화할 수 있습니다.
Webhook은 데이터 “참신성”, 통신의 효율성, 보안 측면에서 더 유용합니다. 폴링은 필요하지 않습니다.
Webhook을 사용하면 다양한 수준의 범위(계정/그룹/사용자/리소스)를 쉽게 지원할 수 있습니다,
Webhook은 최신 API 솔루션으로, 최신 애플리케이션을 더 간단하게 구성할 수 있습니다.
각 범위(계정/그룹/사용자/리소스)에 대해 여러 Webhook을 구성할 수 있습니다. 여기서 콜백은 고유해야 합니다.
Webhook을 사용하면 반환할 데이터를 선택할 수 있습니다. 여기서 콜백은 "전부 아니면 전무" 솔루션입니다.
Webhook과 함께 제공되는 메타데이터를 구성할 수 있습니다(기본 또는 상세).
UI가 전적으로 관리자의 제어 범위 내에 있으므로 Webhook을 필요에 따라 훨씬 쉽게 생성, 편집 또는 비활성화할 수 있습니다.

참고:

이 문서에서는 주로 Acrobat Sign 웹 애플리케이션(이전 Adobe Sign)의 Webhook UI를 중점적으로 다룹니다.

API 세부 정보를 찾는 개발자는 여기에서 추가 정보를 찾을 수 있습니다.

REST v6 세부 정보

사용되는 방식

관리자는 먼저 Acrobat Sign의 인바운드 푸시를 수락할 준비가 된 Webhook 서비스를 보유해야 합니다. 관련된 많은 옵션이 있으며, 서비스가 POST 및 GET 요청을 수락할 수 있는 한 Webhook은 성공적으로 실행됩니다.

서비스가 준비되면 Acrobat Sign 관리자는 Acrobat Sign 사이트의 계정 메뉴에 있는 Webhook 인터페이스에서 새 Webhook을 생성할 수 있습니다.

관리자는 계약, 웹 양식(위젯) 또는 대량 전송(MegaSign) 이벤트를 트리거하도록 Webhook을 구성할 수 있습니다. 라이브러리 템플릿(라이브러리 문서) 리소스는 API를 통해 구성할 수도 있습니다.

Webhook의 범위는 관리자 인터페이스를 통해 전체 계정 또는 개별 그룹을 포함할 수 있습니다. API를 사용하면 사용자 또는 리소스 범위를 선택하여 더 세분화할 수 있습니다.

URL로 푸시되는 데이터 유형은 구성 가능하며 계약 정보, 참가자 정보, 문서 정보 등과 같은 항목을 포함할 수 있습니다.

Webhook이 구성되고 저장되면 Acrobat Sign은 구독 이벤트가 트리거될 때마다 새로운 JSON 개체를 정의된 URL로 푸시합니다. 이벤트 트리거 조건이나 JSON 페이로드를 변경하려는 경우가 아니라면 Webhook을 계속 조작할 필요가 없습니다.

Webhook URL의 의도 확인

Webhook을 성공적으로 등록하기 전에 Acrobat Sign은 등록 요청에서 제공된 Webhook URL이 알림을 수신할 것인지 여부를 확인합니다. 이를 위해 Acrobat Sign은 새 Webhook 등록 요청을 받으면 먼저 Webhook URL에 대한 확인 요청을 합니다. 이 확인 요청은 Webhook URL로 전송된 HTTPS GET 요청입니다. 이 요청에는 사용자 지정 HTTP 헤더 X-AdobeSign-ClientId가 있습니다. 이 헤더의 값은 Webhook 생성/등록을 요청하는 API 애플리케이션의 클라이언트 ID(애플리케이션 ID)로 설정됩니다. Webhook을 성공적으로 등록하려면 Webhook URL은 이 확인 요청에 2XX 응답 코드로 응답해야 하며 다음 두 가지 방법 중 하나로 동일한 클라이언트 ID 값을 다시 전송해야 합니다.

응답 헤더 X-AdobeSign-ClientId에서 이는 요청에서 전달되는 동일한 헤더로 응답에서 다시 반복됩니다.
또는 xAdobeSignClientId 키가 포함된 JSON 응답 본문에서 해당 값은 요청에서 전송된 것과 동일한 클라이언트 ID입니다.

Webhook은 성공 응답(2XX 응답 코드) 및 헤더 또는 응답 본문의 클라이언트 ID 유효성 검사에만 성공적으로 등록됩니다. 이 확인 요청의 목적은 Webhook URL이 해당 URL에서 알림을 수신하기를 원한다는 것을 보여주기 위한 것입니다. 실수로 잘못된 URL을 입력한 경우 URL이 의도 요청 확인에 올바르게 응답하지 않으며 Acrobat Sign이 해당 URL에 알림을 전송하지 않습니다. 또한 Webhook URL은 특정 애플리케이션에서 등록한 Webhook을 통해서만 알림을 수신하는지 확인할 수도 있습니다. 이 작업은 X-AdobeSign-ClientId 헤더에 전달된 애플리케이션의 클라이언트 ID를 유효성 검사하여 수행할 수 있습니다. Webhook URL이 해당 클라이언트 ID를 인식하지 못하면 성공 응답 코드로 응답하지 않아야 하며, Acrobat Sign은 URL이 Webhook으로 등록되지 않도록 처리합니다.

Webhook URL 호출의 확인은 다음 시나리오에서 수행됩니다.

Webhook 등록: 이 Webhook URL 호출 확인에 실패하면 Webhook이 생성되지 않습니다.
Webhook 업데이트: INACTIVE - ACTIVE: 이 Webhook URL 호출 확인에 실패하면 Webhook 상태가 ACTIVE로 변경되지 않습니다.

Webhook 알림에 응답하는 방법

Acrobat Sign은 Webhook URL로 전송되는 각 Webhook 알림 요청에서 의도를 암시적으로 확인합니다. 따라서 모든 Webhook 알림 HTTPS 요청에는 X-AdobeSign-ClientId라는 사용자 지정 HTTP 헤더도 포함됩니다. 이 헤더의 값은 Webhook을 생성한 애플리케이션의 클라이언트 ID(애플리케이션 ID)입니다. 성공 응답(2XX 응답 코드)이 반환되고 클라이언트 ID가 HTTP 헤더(X-AdobeSign-ClientId)로 전송되거나 키가 xAdobeSignClientId이고 값이 동일한 클라이언트 ID인 JSON 응답 본문을 통해 전송되는 경우에만 Webhook 알림이 성공적으로 전달된 것으로 간주합니다. 그렇지 않으면 재시도 횟수가 모두 소진될 때까지 Webhook URL로 알림 전달을 다시 시도합니다.

위에 언급한 것처럼 Sign의 모든 알림 요청에 포함된 헤더 'X-AdobeSign-ClientId'와 이 헤더의 값(클라이언트 ID)을 다음 두 가지 방법 중 하나로 응답에서 다시 반복해야 합니다.

1. HTTP 헤더 X-AdobeSign-ClientId 및 이 클라이언트 ID인 값

클라이언트 ID를 가져오고 유효성을 검사한 다음 응답 헤더에 반환하는 샘플 Javascript 코드
//클라이언트 ID를 가져옵니다. var clientid = request.headers['X-ADOBESIGN-CLIENTID']; //유효성을 검사합니다. if (clientid ==="BGBQIIE7H253K6") //'BGBQIIE7H253K6'을 Webhook을 생성하는 데 사용하는 애플리케이션의 클라이언트 ID로 교체합니다. { //응답 헤더에 반환합니다. response.headers['X-AdobeSign-ClientId'] = clientid; response.status = 200; //기본값 }

클라이언트 ID를 가져오고 유효성을 검사한 다음 응답 헤더에 반환하는 샘플 Javascript 코드

//클라이언트 ID를 가져옵니다.

var clientid = request.headers['X-ADOBESIGN-CLIENTID'];

//유효성을 검사합니다.

if (clientid ==="BGBQIIE7H253K6") //'BGBQIIE7H253K6'을 Webhook을 생성하는 데 사용하는 애플리케이션의 클라이언트 ID로 교체합니다.

{

//응답 헤더에 반환합니다.

response.headers['X-AdobeSign-ClientId'] = clientid;

response.status = 200; //기본값

}

클라이언트 ID를 가져오고 유효성을 검사한 다음 응답 헤더에 반환하는 샘플 PHP 코드
<?php //클라이언트 ID를 가져옵니다. $clientid = $_SERVER['HTTP_X_ADOBESIGN_CLIENTID']; //유효성을 검사합니다. if($clientid == "BGBQIIE7H253K6") //'BGBQIIE7H253K6'을 Webhook을 생성하는 데 사용하는 애플리케이션의 클라이언트 ID로 교체합니다. { //응답 헤더에 반환합니다. header("X-AdobeSign-ClientId:$clientid"); header("HTTP/1.1 200 OK"); // default value } ?>

클라이언트 ID를 가져오고 유효성을 검사한 다음 응답 헤더에 반환하는 샘플 PHP 코드

<?php

//클라이언트 ID를 가져옵니다.

$clientid = $_SERVER['HTTP_X_ADOBESIGN_CLIENTID'];

//유효성을 검사합니다.

if($clientid == "BGBQIIE7H253K6") //'BGBQIIE7H253K6'을 Webhook을 생성하는 데 사용하는 애플리케이션의 클라이언트 ID로 교체합니다.

{

//응답 헤더에 반환합니다.

header("X-AdobeSign-ClientId:$clientid");

header("HTTP/1.1 200 OK"); // default value

}

2. 키가 xAdobeSignClientId이고 값이 동일한 클라이언트 ID인 JSON 응답 본문

클라이언트 ID를 가져오고 유효성을 검사한 다음 응답 본문에 반환하는 샘플 Javascript 코드
//클라이언트 ID를 가져옵니다. var clientid = request.headers['X-ADOBESIGN-CLIENTID']; //유효성을 검사합니다. if (clientid ==="BGBQIIE7H253K6") //'BGBQIIE7H253K6'을 Webhook을 생성하는 데 사용하는 애플리케이션의 클라이언트 ID로 교체합니다. { var responseBody = { "xAdobeSignClientId" : clientid // Return Client Id in the body }; response.headers['Content-Type'] = 'application/json'; response.body = responseBody; response.status = 200; }

클라이언트 ID를 가져오고 유효성을 검사한 다음 응답 본문에 반환하는 샘플 Javascript 코드

//클라이언트 ID를 가져옵니다.

var clientid = request.headers['X-ADOBESIGN-CLIENTID'];

//유효성을 검사합니다.

if (clientid ==="BGBQIIE7H253K6") //'BGBQIIE7H253K6'을 Webhook을 생성하는 데 사용하는 애플리케이션의 클라이언트 ID로 교체합니다.

{

var responseBody = {

"xAdobeSignClientId" : clientid // Return Client Id in the body

};

response.headers['Content-Type'] = 'application/json';

response.body = responseBody;

response.status = 200;

}

클라이언트 ID를 가져오고 유효성을 검사한 다음 응답 본문에 반환하는 샘플 PHP 코드
<?php //클라이언트 ID를 가져옵니다. $clientid = $_SERVER['HTTP_X_ADOBESIGN_CLIENTID']; //유효성을 검사합니다. if($clientid == "BGBQIIE7H253K6") //'BGBQIIE7H253K6'을 Webhook을 생성하는 데 사용하는 애플리케이션의 클라이언트 ID로 교체합니다. { //Return it in response body header("Content-Type: application/json"); $body = array('xAdobeSignClientId' => $clientid); echo json_encode($body); header("HTTP/1.1 200 OK"); // default value } ?>

클라이언트 ID를 가져오고 유효성을 검사한 다음 응답 본문에 반환하는 샘플 PHP 코드

<?php

//클라이언트 ID를 가져옵니다.

$clientid = $_SERVER['HTTP_X_ADOBESIGN_CLIENTID'];

//유효성을 검사합니다.

if($clientid == "BGBQIIE7H253K6") //'BGBQIIE7H253K6'을 Webhook을 생성하는 데 사용하는 애플리케이션의 클라이언트 ID로 교체합니다.

{

//Return it in response body

header("Content-Type: application/json");

$body = array('xAdobeSignClientId' => $clientid);

echo json_encode($body);

header("HTTP/1.1 200 OK"); // default value

}

응답의 샘플 JSON 본문
{ "xAdobeSignClientId": "BGBQIIE7H253K6" }

사전 요구 사항

필수 항목:

Azure 함수 애플리케이션을 만들기 위한 라이선스가 있는 Microsoft 계정
기존 Azure 함수 애플리케이션은 https://docs.microsoft.com/ko-kr/azure/azure-functions/functions-create-first-azure-function을 사용하여 만들 수 있습니다.
원하는 언어로 코드를 이해하고 작성할 수 있도록 하기 위한 자바스크립트에 대한 기본 지식

Acrobat Sign Webhook 역할을 하는 Azure 함수 트리거를 만드는 단계

Javascript HTTP Trigger 함수를 생성하는 방법은 다음과 같습니다.

1. Microsoft 계정을 통해 로그인합니다(https://portal.azure.com/).

2. 함수 앱 탭에 표시된 Azure 함수 애플리케이션을 엽니다.

Azure 함수 애플리케이션 목록이 열립니다.

3. 이 새 함수를 만들 애플리케이션을 선택합니다.

4. 만들기(+) 버튼을 클릭하여 새 Azure 함수를 만듭니다.

5. Webhook + API를 시나리오로 선택하고 Javascript를 언어로 선택합니다.

6. 이 함수 만들기를 클릭합니다.

수신 API 요청을 처리할 수 있는 새 함수가 만들어집니다.

Acrobat Sign Webhook을 등록하는 논리 추가

Webhook을 성공적으로 등록하기 전에 Acrobat Sign은 등록 요청에서 제공된 Webhook URL이 실제로 알림을 수신할 의도가 있는지 여부를 확인합니다. 이를 위해 Acrobat Sign에서 새로운 Webhook 등록 요청을 받으면 우선 Webhook URL에 확인 요청을 합니다. 이 확인 요청은 사용자 지정 HTTP 헤더 X-AdobeSign-ClientId가 있는 Webhook URL로 전송되는 HTTPS GET 요청입니다. 이 헤더의 값은 Webhook 생성/등록을 요청하는 애플리케이션의 클라이언트 ID로 설정됩니다. Webhook을 성공적으로 등록하기 위하여 Webhook URL은 2XX 응답 코드로 해당 확인 요청에 응답해야 하며 다음 두 가지 방법 중 하나로 동일한 클라이언트 ID 값을 다시 전송해야 합니다.

다음과 같은 두 가지 옵션을 사용할 수 있습니다.

옵션 1. X-AdobeSign-ClientId의 클라이언트 ID를 응답 헤더로 전달

X-AdobeSign-ClientId를 응답 헤더로 전달합니다. 이는 요청에서 전달되는 동일한 헤더로 응답에서 다시 반복해야 합니다.

Index.js 파일을 다음으로 바꿉니다.

module.exports = function (context, req) {

var clientId = req.headers['x-adobesign-clientid'];

//수신 ClientID가 정품인지 확인합니다.

if (clientId === '123XXX456') {

context.res = {

// status: 200, /* Defaults to 200 */ // 모든 2XX 응답이 허용됩니다.

body: "Notification Accepted",

headers : {

'x-adobesign-clientid' : req.headers['x-adobesign-clientid']

}

};

}

else {

context.res = {

status: 400,

body: "Opps!! Illegitimate Call identified"

};

}

context.done();

};

요청 시안을 만들어 동작을 테스트합니다.

1.맨 오른쪽 모서리에 있는 테스트 버튼을 클릭합니다.

2. 더미 요청 시안을 만듭니다.

응답 헤더는 위에 표시되지 않지만, postman/DHC 또는 기타 다른 서비스로 시안을 만들어 관찰할 수 있습니다.

옵션 2. xAdobeSignClientId 키를 사용하여 응답 본문에 클라이언트 ID 전달

xAdobeSignClientId 키가 포함된 JSON 응답 본문에서 해당 값은 요청에서 전송된 것과 동일한 클라이언트 ID입니다.

Index.js 파일을 다음으로 바꿉니다.

module.exports = function (context, req) {

var clientId = req.headers['x-adobesign-clientid'];

//수신 ClientID가 정품인지 확인합니다.

if (clientId === '123XXX456') {

context.res = {

// status: 200, /* Defaults to 200 */ // 모든 2XX 응답이 허용됩니다.

body: {

'xAdobeSignClientId' : clientId

headers : {

'Content-Type' : 'application/json'

}

};

}

else {

context.res = {

status: 400,

body: "Opps!! Illegitimate Call identified"

};

}

context.done();

};

요청 시안을 만들어 동작을 테스트합니다.

1.맨 오른쪽 모서리에 있는 테스트 버튼을 클릭합니다.

2. 더미 요청 시안을 만듭니다.

또한 Webhook URL이 POST 알림을 받을 때 clientID에 대해서도 동일한 동작이 예상됩니다.

사용 준비됨

동작을 확인하면 Acrobat Sign 표준에 따라 Webhook URL이 작동합니다. 요구 사항에 따라 사용자 지정 논리를 추가로 업데이트할 수 있습니다.

함수 URL 가져오기

함수 URL 가져오기를 클릭합니다.

URL을 복사하여 Acrobat Sign에서 Webhook을 만드는 데 사용합니다.

AWS Lambda 함수 만들기

AWS Lambda 함수를 만들려면 AWS Management Console에 로그인하여 서비스 목록에서 AWS Lambda 서비스를 선택합니다.

"처음부터 작성"을 사용하여 Lambda 함수 만들기 옵션을 클릭합니다.
함수 구성 페이지에서 기능 이름 "lambdaWebhooks"를 입력하고 Node.js 4.3을 런타임으로 선택합니다.
역할의 경우 기존 역할을 선택하거나 템플릿에서 새 역할을 만듭니다.
- 템플릿에서 새 역할 만들기를 선택한 경우 역할 이름(예: role-lambda)을 입력하고 정책 템플릿 목록에서 단순 마이크로서비스 권한을 선택합니다.
함수 생성 버튼을 클릭합니다.

새 AWS Lambda 함수 페이지에서 "코드 인라인 편집"을 "코드 입력 유형"으로 선택하고 index.handler를 핸들러로 유지합니다.
Acrobat Sign Webhook을 등록하는 논리 추가
Webhook을 성공적으로 등록하기 전에 Acrobat Sign은 등록 요청에서 제공된 Webhook URL이 실제로 알림을 수신할 의도가 있는지 여부를 확인합니다. 이를 위해 Acrobat Sign에서 새로운 Webhook 등록 요청을 받으면 우선 Webhook URL에 확인 요청을 합니다. 이 확인 요청은 사용자 지정 HTTP 헤더 X-AdobeSign-ClientId가 있는 Webhook URL로 전송되는 HTTPS GET 요청입니다. 이 헤더의 값은 Webhook 생성/등록을 요청하는 애플리케이션의 클라이언트 ID로 설정됩니다. Webhook을 성공적으로 등록하기 위하여 Webhook URL은 2XX 응답 코드로 해당 확인 요청에 응답해야 하며 다음 두 가지 방법 중 하나로 동일한 클라이언트 ID 값을 다시 전송해야 합니다. 또한 Webhook URL이 POST 알림을 받을 때 clientID에 대해서도 동일한 동작이 예상됩니다.

다음 두 가지 경우 중 하나를 수행합니다.

사례 1: X-AdobeSign-ClientId의 클라이언트 ID를 응답 헤더로 전달
- X-AdobeSign-ClientId를 응답 헤더로 전달합니다. 이는 요청에서 전달되는 동일한 헤더로 응답에서 다시 반복해야 합니다.
  
  코드 조각
  index.js 파일에서 자동으로 생성된 코드 조각을 다음 코드로 바꿉니다.

클라이언트 ID를 가져오고 유효성을 검사한 다음 응답 헤더에 반환하는 샘플 노드 JS 코드
exports.handler = function index(event, context, callback) { //클라이언트 ID를 가져옵니다. var clientid = event.headers['X-AdobeSign-ClientId']; //유효성을 검사합니다. if (clientid =="BGBQIIE7H253K6") //'BGBQIIE7H253K6'을 Webhook을 생성하는 데 사용하는 애플리케이션의 클라이언트 ID로 교체합니다. { var response = { statusCode: 200, headers: { "X-AdobeSign-ClientId": clientid } }; callback(null,response); } else { callback("Oops!! illegitimate call"); } }

클라이언트 ID를 가져오고 유효성을 검사한 다음 응답 헤더에 반환하는 샘플 노드 JS 코드

exports.handler = function index(event, context, callback) {

//클라이언트 ID를 가져옵니다.

var clientid = event.headers['X-AdobeSign-ClientId'];

//유효성을 검사합니다.

if (clientid =="BGBQIIE7H253K6") //'BGBQIIE7H253K6'을 Webhook을 생성하는 데 사용하는 애플리케이션의 클라이언트 ID로 교체합니다.

{

var response = {

statusCode: 200,

headers: {

"X-AdobeSign-ClientId": clientid

}

};

callback(null,response);

}

else {

callback("Oops!! illegitimate call");

}

사례 2: xAdobeSignClientId 키를 사용하여 응답 본문에 클라이언트 ID 전달

xAdobeSignClientId 키가 포함된 JSON 응답 본문에서 해당 값은 요청에서 전송된 것과 동일한 클라이언트 ID입니다.

코드 조각

Index.js 파일을 다음으로 바꿉니다.

클라이언트 ID를 가져오고 유효성을 검사한 다음 응답 헤더에 반환하는 샘플 노드 JS 코드
exports.handler = function index(event, context, callback) { //클라이언트 ID를 가져옵니다. var clientid = event.headers['X-AdobeSign-ClientId']; //유효성을 검사합니다. if (clientid =="BGBQIIE7H253K6") //'BGBQIIE7H253K6'을 Webhook을 생성하는 데 사용하는 애플리케이션의 클라이언트 ID로 교체합니다. { var responseBody = { xAdobeSignClientId : clientid }; var response = { statusCode: 200, body: JSON.stringify(responseBody) }; callback(null,response); } else { callback("Opps!! illegitimate call"); } }

클라이언트 ID를 가져오고 유효성을 검사한 다음 응답 헤더에 반환하는 샘플 노드 JS 코드

exports.handler = function index(event, context, callback) {

//클라이언트 ID를 가져옵니다.

var clientid = event.headers['X-AdobeSign-ClientId'];

//유효성을 검사합니다.

if (clientid =="BGBQIIE7H253K6") //'BGBQIIE7H253K6'을 Webhook을 생성하는 데 사용하는 애플리케이션의 클라이언트 ID로 교체합니다.

{

var responseBody = {

xAdobeSignClientId : clientid

};

var response = {

statusCode: 200,

body: JSON.stringify(responseBody)

};

callback(null,response);

}

else {

callback("Opps!! illegitimate call");

}

함수를 저장합니다. Lambda 함수가 생성되며 실시간 Webhook에서 사용할 준비가 거의 다 되었습니다.

AWS API Gateway 구성

HTTP 메서드를 통해 이 Lambda에 공개적으로 액세스할 수 있도록 하려면 위에서 만든 함수를 API의 백엔드로 사용하여 AWS API Gateway를 구성해야 합니다.

AWS Management Console의 AWS 서비스에서 API Gateway를 선택하고 API 만들기 버튼을 클릭합니다.

새 API 만들기 페이지에서 새 API를 선택하고 webhooks를 API 이름으로 입력합니다.
API 만들기 버튼을 클릭합니다.
작업 드롭다운 목록을 선택하고 리소스 만들기 옵션을 선택합니다.
프록시 리소스로 구성 옵션을 확인하고 validate를 리소스 이름으로, {proxy+}를 리소스 경로로 입력합니다.
API Gateway CORS 활성화 옵션을 선택 취소된 상태로 유지하고 리소스 만들기 버튼을 클릭합니다.
Lambda 함수 프록시를 통합 유형으로 선택된 상태로 유지하고 Lambda 리전 드롭다운 목록에서 Lambda 함수를 만든 리전을 선택합니다(API Gateway를 생성하는 리전과 동일한 리전일 수 있음).
validate를 Lambda 함수로 입력하고 저장 버튼을 클릭합니다.
Lambda 함수에 권한 추가 팝업 창에서 확인을 선택합니다.

위의 모든 단계가 성공적으로 실행되면 다음과 같은 항목이 표시됩니다.

API 배포

다음 단계는 이 API를 배포하여 사용할 준비를 하는 것입니다.

작업 드롭다운에서 API 배포를 선택합니다.
배포 단계에서 [새 단계]를 선택하고 단계 이름에 prod(또는 이 단계를 식별할 수 있는 모든 것)를 입력합니다.
배포 버튼을 클릭합니다.

이제 API를 사용할 준비가 되었으며 아래와 같이 파란색 상자에서 호출 URL을 찾을 수 있습니다.

이 URL은 실시간 Webhook URL로 입력해야 하므로 기록해 두세요.

사용 준비됨

완료되었습니다. POST /webhooks API 요청에서 webhook url로 추가된 "/{nodeJSfunctionName}"과 함께 위 URL을 사용하세요. 동작을 확인하면
Acrobat Sign 표준에 따라 Webhook URL이 작동합니다. 요구 사항에 따라 사용자 지정 논리를 추가로 업데이트/추가할 수 있습니다.

구성 옵션

Webhook을 구성하려면 5개 요소를 정의해야 합니다.

이름 - 관리자가 쉽게 이해할 수 있는 직관적인 이름이 권장됩니다.
범위 - Webhook의 도달 범위입니다. 인터페이스에서 계정 및 그룹을 사용할 수 있습니다.
- API에서는 계정, 그룹, 사용자 및 리소스 범위를 지원합니다.
- Webhook당 하나의 범위만 정의할 수 있습니다.
URL - Adobe Sign이 JSON 페이로드를 푸시한 대상 URL입니다.
이벤트 - Adobe Sign이 JSON을 빌드하고 URL로 푸시하도록 하는 트리거입니다.
- 각 이벤트는 트리거 이벤트와 관련된 다른 페이로드를 빌드합니다.
- 하나의 Webhook에 여러 이벤트가 포함될 수 있습니다.
알림 매개변수 - 알림 매개변수는 이벤트 JSON 페이로드의 섹션을 식별하므로 이 Webhook에 중요한 이벤트 섹션만 선택할 수 있으며, 따라서 URL로 전송하는 불필요한 데이터가 감소됩니다.

Webhook이 완벽히 정의된 후 저장을 클릭하면 새 Webhook이 반응하여 즉시 이벤트를 트리거합니다.

참고:

위에 설명된 확인 프로토콜에 따라 Webhook 확인 및 Webhook 알림 요청에 응답하도록 Webhook URL을 구성하세요. Acrobat Sign 웹 애플리케이션에서 생성된 Webhook으로 전송되는 클라이언트 ID(애플리케이션 ID)는 UB7E5BXCXY입니다.

범위

계정: 계정에서 발생하는 모든 구독 이벤트는 푸시를 트리거합니다.
- 계정 관리자는 계정 및 해당 계정 내의 모든 그룹에 대해 정의된 모든 Webhook을 볼 권한이 있습니다.
그룹: 그룹에서 발생하는 모든 구독 이벤트는 푸시를 트리거합니다. 참고: 그룹 범위 Webhook은 하나의 해당 그룹에 대해서만 존재합니다.
- 그룹 관리자는 해당 그룹 전용 Webhook만 볼 수 있습니다. 계정 수준 Webhook 또는 다른 그룹에 바인딩된 Webhook은 볼 수 없습니다.
- 다중 그룹의 사용자가 활성화된 계정에는 범위를 적용해야 하는 그룹을 설정하는 옵션이 표시됩니다.
사용자 계정: 사용자 계정에 대한 모든 구독 이벤트는 푸시를 트리거합니다. 사용자 수준 Webhook은 API를 통해서만 만들 수 있습니다.
리소스 수준 Webhook: 특정 리소스에 대해 생성됩니다. 이 리소스와 관련된 이벤트는 Webhook URL로 푸시됩니다. 리소스 수준 Webhook은 API를 통해서만 만들 수 있습니다.

URL

Webhook URL은 이벤트가 발생할 때 트리거되는 수신 HTTPS POST 알림 메시지를 수신 대기하는 서버입니다.

Webhook에서 이벤트를 구독하려면 이 URL이 필요합니다.

클라이언트에는 Acrobat Sign이 POST할 수 있는 HTTPS URL이 포함되어야 합니다. 이 URL은 공용 인터넷에서 사용할 수 있어야 합니다.
- 예를 들어 127.0.0.1 및 localhost URI는 작동하지 않습니다.
- URL 엔드포인트는 포트 443 또는 8443에서 수신 대기해야 합니다(콜백 URL을 정의할 때 고객이 결정).
Webhook에서 수신 이벤트 알림에 대한 POST 요청과 확인 요청에 대한 GET 요청을 지원하는지 확인합니다.
URL은 방화벽으로 차단해서는 안 됩니다.

이벤트

다음은 Webhook URL로 푸시를 트리거할 수 있는 이벤트로서, 개체별로 그룹화되고 UI에 있는 순서대로 나열됩니다.

왼쪽 값은 Acrobat Sign UI에 표시되는 값입니다. 오른쪽 값은 API에서 Webhook 이름입니다.

Webhook 및 해당 페이로드에 대한 자세한 내용은 Acrobat Sign 개발자 안내서를 참조하세요.

계약:

UI 요소	Webhook 이름
계약 모든 이벤트	AGREEMENT_ALL
계약이 생성됨	AGREEMENT_CREATED
계약서 전송됨	AGREEMENT_ACTION_REQUESTED
계약 참가자가 완료함	AGREEMENT_ACTION_COMPLETED
계약 워크플로우가 완료됨	AGREEMENT_WORKFLOW_COMPLETED
계약이 만료됨	AGREEMENT_EXPIRED
계약이 삭제됨	AGREEMENT_DOCUMENTS_DELETED
계약이 취소됨	AGREEMENT_RECALLED
계약이 거부됨	AGREEMENT_REJECTED
계약이 공유됨	AGREEMENT_SHARED
계약이 위임됨	AGREEMENT_ACTION_DELEGATED
계약 참가자가 교체됨	AGREEMENT_ACTION_REPLACED_SIGNER
계약이 수정됨	AGREEMENT_MODIFIED
계약 수정이 승인됨	AGREEMENT_USER_ACK_AGREEMENT_MODIFIED
계약 이메일을 봄	AGREEMENT_EMAIL_VIEWED
계약 이메일이 반송됨	AGREEMENT_EMAIL_BOUNCED
계약 작성 실패	AGREEMENT_AUTO_CANCELLED_CONVERSION_PROBLEM
계약이 동기화된 사후 오프라인 이벤트	AGREEMENT_OFFLINE_SYNC
발신자가 계약을 업로드함	AGREEMENT_UPLOADED_BY_SENDER
계약이 보관됨	AGREEMENT_VAULTED
계약 참가자 소셜 신원이 인증됨	AGREEMENT_WEB_IDENTITY_AUTHENTICATED
계약 참가자 KBA가 인증됨	AGREEMENT_KBA_AUTHENTICATED
계약 알림 전송됨	AGREEMENT_REMINDER_SENT
서명자가 계약 서명자 이름을 변경함	AGREEMENT_SIGNER_NAME_CHANGED_BY_SIGNER

계약 Webhook는 API를 통해서만 사용 가능
NA	AGREEMENT_EXPIRATION_UPDATED
NA	AGREEMENT_READY_TO_NOTARIZE
NA	AGREEMENT_READY_TO_VAULT

대량 전송:

UI 요소	Webhook 이름
모든 이벤트 대량 전송	MEGASIGN_ALL
대량 전송 생성됨	MEGASIGN_CREATED
대량 전송 공유됨	MEGASIGN_SHARED
대량 전송 회수됨	MEGASIGN_RECALLED

웹 양식:

UI 요소	Webhook 이름
웹 양식 모든 이벤트	WIDGET_ALL
웹 양식이 생성됨	WIDGET_CREATED
웹 양식이 활성화됨	WIDGET_ENABLED
웹 양식이 비활성화됨	WIDGET_DISABLED
웹 양식이 수정됨	WIDGET_MODIFIED
웹 양식이 공유됨	WIDGET_SHARED
웹 양식 생성 실패	WIDGET_AUTO_CANCELLED_CONVERSION_PROBLEM

라이브러리 템플릿(API만 해당):

UI 요소	Webhook 이름
NA	LIBRARY_DOCUMENT_ALL
NA	LIBRARY_DOCUMENT_CREATED
NA	LIBRARY_DOCUMENT_AUTO_CANCELLED_CONVERSION_PROBLEM
NA	LIBRARY_DOCUMENT_MODIFIED

알림 매개변수

알림 매개변수를 사용하면 JSON 페이로드를 이벤트의 특정 요소에만 맞게 사용자 지정할 수 있습니다.

예를 들어, 계약 참가자 교체 이벤트에서 문서 정보는 생략하고 Webhook URL로 전송되는 JSON의 전체 크기를 줄이고 계약 정보 및 참가자 정보만 원할 수 있습니다.

계약
- 계약 정보 - 트리거 이벤트 발생 시의 계약 상태를 기반으로 하는 자세한 계약 정보입니다.
- 계약 문서 정보 - 이벤트의 결과로 생성된 모든 문서 정보를 포함합니다.
- 계약 참가자 정보 - 이벤트의 결과로 모든 참가자 정보를 포함합니다.
- 서명된 계약 문서 - 서명된 PDF를 제공합니다.
  - 계약 워크플로우 완료 및 모두 계약 이벤트에 적용됩니다.
대량 전송
- 대량 전송 정보 - 이벤트를 트리거한 대량 전송 개체에 대한 자세한 정보입니다.
웹 양식
- 위젯 정보 - 이벤트를 트리거한 웹 양식에 대한 자세한 정보입니다.
- 위젯 문서 정보 - 웹 양식과 연결된 문서 정보입니다.
- 위젯 참가자 정보 - 웹 양식에 정의된 참가자에 대한 정보입니다.

양방향 SSL 인증

클라이언트측 SSL 또는 상호 TLS라고도 하는 양방향 SSL은 서버 및 클라이언트(웹 브라우저)가 모두 자신을 식별하기 위한 인증서를 제공하는 SSL 모드입니다.

계정 관리자는 보안 설정 페이지에서 클라이언트측 인증서를 구성할 수 있습니다.

Acrobat Sign은 페이로드를 Webhook URL로 전달할 때 SSL 인증서를 확인합니다. SSL 인증서 확인에 실패한 Webhook은 JSON 페이로드를 성공적으로 전달하지 않습니다.

양방향 SSL을 사용하여 클라이언트(Acrobat Sign) 및 수신 대기 서비스를 인증하면 Acrobat Sign만 Webhook URL에 연결할 수 있습니다.

파트너 애플리케이션에 의해 생성된 Webhook은 Webhook 알림을 전송할 때 파트너 애플리케이션 계정의 클라이언트 인증서(사용 가능한 경우)를 사용하여 자체 식별합니다.

SSL/TSL 요구 사항에 대해 자세히 알아보세요.

다음은 웹 서버 확인 프로세스와 클라이언트 인증 확인에 대한 가장 일반적인 질문입니다.

웹 서버 확인

Webhook을 등록하는 동안 Acrobat Sign은 Webhook 서버 URL을 확인합니다.

Acrobat Sign에서 Webhook 콜백 URL에 대한 연결을 완료할 수 없는 경우 고객은 Webhook를 등록할 수 없습니다.

아니요.

Webhook 콜백 URL은 포트 443 또는 8443의 HTTPS만 가능합니다.

Acrobat Sign은 모든 다른 포트로 가는 아웃바운드 HTTPS 트래픽을 차단합니다.

서버 인증서를 확인하는 좋은 방법은 DigiCert® SSL 설치 진단 도구를 사용하는 것입니다.

호스트 이름만 입력합니다. 예: www.digicert.com

일반적인 문제는 다음과 같습니다.

문제: 신뢰할 수 없는 CA 또는 자체 서명된 인증서 사용

수정: Webhook 콜백 서버에 대한 공개 CA 발급 SSL 인증서를 사용합니다.

문제: 서버가 중간 인증서를 보내지 않습니다.

수정: Webhook 콜백 서버에 중간 인증서를 설치합니다.

자세한 내용은 https://www.digicert.com/kb/ssl-certificate-installation.htm을 참조하세요.

클라이언트 인증서 확인

Webhook에 대해 양방향 SSL을 설정하려면 관리자가 개인 키가 포함된 .p12(또는 .pfx) 파일을 업로드해야 합니다. 파일은 고객 계정 내에 안전하게 저장되며 관리자가 언제든 제거할 수 있는 모든 권한을 갖습니다.

양방향 Webhook 설정에서, Acrobat Sign은 발신자/클라이언트이며, 고객 계정을 대신하여 Acrobat Sign이 호출하는 것임을 증명하기 위해 개인 키가 필요합니다.

양방향 SSL이 활성화되었는지 확인

Webhook 콜백 서버에 양방향 SSL이 활성화되어야 합니다.

웹 브라우저를 사용하여 Webhook 콜백 URL에 연결합니다. 다음 메시지가 표시됩니다.
```
400 잘못된 요청
필수 SSL 인증서가 전송되지 않았습니다.
```
즉, 서버는 클라이언트가 클라이언트 인증서를 보낼 것으로 예상한다는 뜻입니다(양방향 SSL이 서버에 대해 활성화됨).

위의 메시지가 표시되지 않으면 양방향 SSL이 활성화되지 않은 것입니다.

참고:

Postman을 사용하여 Webhook 콜백 URL에 대한 POST 요청을 수행할 수 있습니다. 비슷한 결과를 얻게 됩니다.

로컬에서 클라이언트 인증서 확인

클라이언트 자격 증명은 자체 서명된 인증서 또는 CA 발급 인증서일 수 있습니다. 단, 최소한 다음 X.509 v3 확장을 준수해야 합니다.

X.509 v3 확장	값
ExtendedKeyUsage	clientAuth(OID: 1.3.6.1.5.5.7.3.2)
KeyUsage	digitalSignature

클라이언트 인증서는 확장명이 .p12 또는 .pfx인 PKCS12 파일이어야 하며 클라이언트 인증서(서버가 클라이언트의 신원을 확인할 수 있도록)와 클라이언트의 개인 키(클라이언트가 SSL 핸드셰이크 중에 서버가 확인할 메시지에 디지털 서명할 수 있도록)를 모두 포함해야 합니다.

openssl 명령을 사용하여 p12(pfx) 파일을 확인:

openssl pkcs12 -info -in outfile.p12

개인 키의 암호를 요청해야 합니다. 출력에는 다음과 같이 두 인증서와 암호화된 개인 키가 모두 포함되어야 합니다.

Bag Attributes
    localKeyID: 9D BD 22 80 E7 B2 B7 58 9E AE C8 42 71 F0 39 E1 E7 2B 57 DB
subject=/C=US/ST=California/L=San Jose/O=Adobe Inc./CN=sp.adobesignpreview.com
issuer=/C=US/O=DigiCert Inc/CN=DigiCert TLS RSA SHA256 2020 CA1
-----BEGIN CERTIFICATE-----
MIIGwDCCBaigAwIBAgIQAhJSKDdyQZjlbYO5MJAYOTANBgkqhkiG9w0BAQsFADBP
MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMSkwJwYDVQQDEyBE
...
JAKQLQ==
-----END CERTIFICATE-----
Bag Attributes: <No Attributes>
subject=/C=US/O=DigiCert Inc/CN=DigiCert TLS RSA SHA256 2020 CA1
issuer=/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root CA
-----BEGIN CERTIFICATE-----
MIIEvjCCA6agAwIBAgIQBtjZBNVYQ0b2ii+nVCJ+xDANBgkqhkiG9w0BAQsFADBh
MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3
...
-----END CERTIFICATE-----
Bag Attributes
    localKeyID: 9D BD 22 80 E7 B2 B7 58 9E AE C8 42 71 F0 39 E1 E7 2B 57 DB
Key Attributes: <No Attributes>
-----BEGIN ENCRYPTED PRIVATE KEY-----
MIIFDjBABgkqhkiG9w0BBQ0wMzAbBgkqhkiG9w0BBQwwDgQI7eNh2qlsLPkCAggA
...
FHE=
-----END ENCRYPTED PRIVATE KEY-----

인증서에는 최소 최종 엔터티 인증서 및 중간 인증서가 포함되어야 합니다. 루트 CA 인증서도 포함하는 것이 좋습니다.

알림:

.p12 또는 .pfx 파일이 암호로 보호되어 있는지 확인합니다.

자체 서명된 클라이언트 인증서 만들기(선택 사항)

클라이언트 인증서는 필요에 따라 CA 발급이거나 자체 서명일 수 있습니다.

자체 서명된 클라이언트 인증서를 생성하려면 다음 openssl 명령을 사용합니다.

openssl req -newkey rsa:4096 -keyform PEM -keyout ca.key -x509 -days 3650 -outform PEM -out ca.cer

경고:

결과 파일은 자체 서명된 CA 인증서이므로 기밀 상태로 유지합니다.
다음으로 클라이언트 .p12 파일을 생성:
1. SSL 클라이언트에 대한 개인 키 생성:
  openssl genrsa -out client.key 2048
2. 클라이언트의 개인 키를 사용하여 인증서 요청 생성:
  openssl req -new -key client.key -out client.req
3. 인증서 요청 및 CA 인증서/키를 사용하여 클라이언트 인증서 발급:
  openssl x509 -req -in client.req -CA ca.cer -CAkey ca.key -set_serial 101 -extensions client -days 365 -outform PEM -out client.cer
4. 클라이언트 인증서 및 개인 키를 브라우저에서 사용할 수 있도록 pkcs#12 형식으로 변환:
  openssl pkcs12 -export -inkey client.key -in client.cer -out client.p12
5. pkcs12에 필요한 모든 것이 있으므로 클라이언트 개인 키, 클라이언트 인증서 및 클라이언트 요청 파일을 제거합니다.
  rm client.key client.cer client.req
원격 서버에 대한 클라이언트 인증서 확인
- Postman을 사용하여 설정 > 인증서에서 클라이언트 PFX 파일을 로드합니다.
- 인증서 추가를 선택하여 클라이언트 인증서를 추가합니다.
- x-adobesign-clientid에 대한 HTTP 헤더를 구성합니다.
구성되면 Webhook 콜백 URL로 POST 요청을 보냅니다.

200 응답을 받게 됩니다.
Postman에서 내 PFX 파일을 확인 받은 후에도 Acrobat Sign에서 파일을 거부하는 이유는 무엇인가요?

위의 pfx 파일 확인 프로세스를 따랐는데도 Acrobat Sign에서 pfx 파일을 계속 거부하면 비표준 PKCS12 파일을 생성할 수 있는 Microsoft 도구로 파일이 생성되었기 때문일 수 있습니다.

이 경우 아래 openssl 명령을 사용하여 pfx 파일에서 인증서 및 개인 키를 추출한 다음, 올바른 형식의 PKCS12 파일을 생성합니다.
```
// pfx 파일에서 인증서 및 개인 키 추출
openssl pkcs12 -info -in microsoftclientssl.pfx -passin pass:&quot;&quot; -out clientcert.crt -nokeys
openssl pkcs12 -info -in microsoftclientssl.pfx -passin pass:&quot;&quot; -out clientcert.key -nodes -nocerts

// 새 PKCS12 파일 생성
openssl pkcs12 -export -inkey clientcert.key -in clientcert.crt -out clientcert.pfx
```

활성화하거나 비활성화하는 방법

Webhooks 기능에 대한 액세스는 엔터프라이즈 플랜 계정에서 기본적으로 활성화되어 있습니다.

그룹 수준 관리자는 해당 그룹 내에서만 작동하는 Webhook을 만들거나 제어할 수 있습니다.

Webhooks 페이지에 대한 액세스는 관리 메뉴의 왼쪽 레일인 계정 > Webhooks에서 찾을 수 있습니다.

Webhook 활성화

Webhook을 처음 만들면 Active 상태로 생성됩니다.

Acrobat Sign의 Webhooks 페이지에는 기본적으로 Active Webhook이 표시됩니다.

Inactive Webhook을 활성화하는 방법은 다음과 같습니다.

Webhook 헤더 행의 오른쪽에서 옵션 아이콘(세 개의 가로 줄)을 클릭하고 모든 Webhook 표시를 선택합니다.

Inactive Webhook을 한 번 클릭하여 선택합니다.
- 그러면 헤더 행 바로 아래에 Webhook에 대한 옵션이 표시됩니다.
활성화를 클릭합니다.

Active Webhook은 다음 이벤트가 트리거되는 즉시 대상 URL로 데이터 전송을 시작합니다.

Webhook 비활성화

Webhook을 비활성화하는 방법은 다음과 같습니다.

Webhooks 페이지로 이동합니다.
비활성화할 Webhook을 한 번 클릭합니다.
헤더 행 아래의 메뉴 항목에서 비활성화를 선택합니다.
- 비활성화하면 Webhook에 Inactive 상태가 표시됩니다.

Webhook 보기 또는 편집

Webhook은 언제든지 편집 및 저장할 수 있으며 새 구성을 저장하면 변경 사항이 즉시 적용됩니다.

이벤트 및 알림 매개변수만 편집할 수 있습니다.

이름, 범위 또는 URL을 변경해야 하는 경우 새 Webhook을 만들어야 합니다.

Webhook 매개변수를 편집하는 방법은 다음과 같습니다.

Webhooks 페이지로 이동합니다.
편집할 Webhook을 한 번 클릭합니다.
헤더 행 아래의 보기/편집 옵션을 선택합니다.

필요한 변경 사항을 적용하고 저장을 클릭합니다.

Webhook 삭제

Webhook은 언제든지 삭제할 수 있습니다.

Webhook을 삭제하면 시스템에서 삭제되므로 삭제된 Webhook을 복구할 수 없습니다.

Webhook을 먼저 비활성화하지 않아도 됩니다.

Webhook을 삭제하는 방법은 다음과 같습니다.

Webhooks로 이동합니다.
삭제할 Webhook을 한 번 클릭하여 선택합니다.
헤더 행 아래의 삭제 옵션을 선택합니다.
Webhook을 삭제할 것인지 확인하는 질문이 표시됩니다. 확인을 클릭합니다.

우수 사례

필요한 특정 이벤트를 구독하여 서버에 대한 HTTPS 요청 수 제한 - Webhook을 구체화할수록 살펴볼 볼륨은 줄어듭니다.
중복 방지 - 동일한 Webhook URL을 공유하는 여러 앱이 있고 동일한 사용자가 각 앱에 매핑된 경우 동일한 이벤트가 여러 번 Webhook로 전송됩니다(앱당 한 번). 경우에 따라 Webhook에서 중복 이벤트를 받을 수 있습니다. Webhook 애플리케이션은 이를 허용해야 하며 이벤트 ID에 의해 중복 제거되어야 합니다.
항상 신속하게 Webhook에 응답 - 앱이 Webhook 요청에 응답할 수 있는 시간은 단 5초입니다. 확인 요청의 경우, 앱에서 응답하기 위해 실제 작업을 수행할 필요가 없으므로 거의 문제가 되지 않습니다. 그러나 알림 요청의 경우, 일반적으로 앱에서 요청에 응답하는 데 시간이 걸리는 작업을 수행합니다. 5초 이내에 응답할 수 있도록 별도의 스레드에서 작업하거나 대기열을 비동기적으로 사용하는 것이 좋습니다.
동시성 관리 - 사용자가 여러 사항을 연속적으로 빠르게 변경하면 앱에서 거의 동시에 동일한 사용자에 대한 여러 알림을 수신할 가능성이 높습니다. 동시성을 관리하는 방법에 대해 주의하지 않으면 앱에서 동일한 사용자에 대한 동일한 변경 내용을 두 번 이상 처리할 수 있습니다. Acrobat Sign Webhook을 활용하려면 정보 사용에 대한 명확한 이해가 필요합니다. 다음과 같이 질문하세요.
- 페이로드에서 어떤 데이터를 반환하시겠습니까?
- 누가 이 정보에 액세스하게 되나요?
- 어떤 결정 또는 보고가 생성되나요?
서명된 문서 수신을 위한 권장 사항 - 문서 관리 시스템에서 Acrobat Sign의 서명된 PDF를 수신하는 방법을 결정할 때 고려할 몇 가지 요소가 있습니다.

Webhook을 만드는 동안 서명된 계약 문서 옵션을 선택하는 것이 완벽하게 허용되지만, 트리거 이벤트(예: 계약 상태 완료)가 수신되면 Acrobat Sign API를 사용하여 문서를 검색하는 것을 고려할 수 있습니다.

주의 사항...

JSON 크기 제한

JSON 페이로드 크기는 10MB로 제한됩니다.

이벤트에서 더 큰 페이로드를 생성하는 경우 Webhook이 트리거되지만 요청에 조건부 매개 변수 속성이 있는 경우 이를 제거하여 페이로드의 크기를 줄입니다.

이런 일이 발생하면 응답에 "ConditionalParametersTrimmed"가 반환되어, 클라이언트에게 conditionalParameters 정보가 제거되었음을 알립니다.

“conditionalParametersTrimmed”는 트리밍된 키에 대한 정보가 포함된 배열 개체입니다.

잘라내기는 다음 순서로 수행됩니다.

includeSignedDocuments
includeParticipantsInfo
includeDocumentsInfo
includeDetailedInfo

서명된 문서가 먼저 잘린 다음 참가자 정보, 문서 정보, 마지막으로 세부 정보가 잘립니다.

예를 들어 서명된 문서(base 64 인코딩)가 포함되어 있는 계약 완료 이벤트에서 또는 여러 양식 필드가 있는 계약에 대해 이러한 문제가 발생할 수 있습니다.

Webhook 알림

Acrobat Sign Webhook은 해당 사용자, 그룹 또는 계정에 대해 구성된 Webhook이 있는 경우, 계약의 모든 참가자에게 적용할 수 있는 알림을 제공합니다.

계약 이벤트는 해당 이벤트의 해당 참가자에 대해 구성된 Webhook이 있는 경우 알림이 해당 Webhook URL로 전송되는 방식으로 처리됩니다. 즉, Webhook이 구성된 그룹 또는 계정 외부의 계약을 포함하여 모든 적용 가능한 계약의 이벤트에 대해 Webhook이 트리거됩니다.

알림은 참가자가 관련된 이벤트에 대해서만 전달됩니다. 예를 들어 계약의 발신자는 거의 모든 알림을 받는 반면, 수신자는 계약에 관여하기 시작할 때부터 직접 관여한 이벤트에 대해서만 알림을 받습니다.

Webhook 알림은 Acrobat Sign 자체의 현재 인증 및 가시성 모델을 따릅니다. 즉, 사용자의 계약 참여가 시작된 경우에만 사용자가 계약에 대한 액세스 권한을 갖게 됩니다.

발신자는 서명할 계약을 세 명의 서명자에게 전송합니다.

발신자 계정에 대해 구성된 계정 수준 WebhookX가 있습니다.
서명자 1은 발신자와 동일한 계정의 멤버이지만 다른 그룹에 속해 있으며 해당 그룹에 대해 구성된 WehbhookY가 있습니다.
서명자 2는 다른 계정의 멤버이며 서명자 2 계정에 대해 구성된 계정 수준 WebhookZ가 있습니다.
서명자 3은 발신자와 동일한 계정의 멤버입니다.

발신자는 계약을 전송합니다. WebhookX는 "계약 생성됨" 및 "계약 전송됨"에 대해 트리거하는 반면 WebhookY는 "계약 전송됨"에 대해 트리거합니다.

서명자 1은 서명합니다. WebhookX는 "계약 참가자 완료됨" 및 "계약 전송됨"에 대해 트리거하고 WebhookY는 "계약 참가자 완료됨"에 대해 트리거하고 WebhookZ는 "계약 전송됨"에 대해 트리거합니다.

서명자 2는 서명합니다. WebhookX는 "계약 참가자 완료됨" 및 "계약 전송됨"에 대해 트리거하는 반면 WebhookZ는 "계약 참가자 완료됨"에 대한 알림을 전송합니다.

서명자 3은 서명합니다. WebhookX는 "계약 참가자 완료됨" 및 "계약 워크플로우 완료됨"에 대해 트리거하고 WebhookY는 "계약 워크플로우 완료됨"에 대해 트리거하고 WebhookZ는 "계약 워크플로우 완료됨"에 대해 트리거합니다.

수신 대기 서비스가 다운되었을 때 다시 시도

Webhook 대상 URL이 다운된 경우 Acrobat Sign은 JSON을 대기열에 추가하고 72시간 동안 점진적 주기로 푸시를 다시 시도합니다.

전달되지 않은 이벤트는 다시 시도 대기열에 유지되며 다음 72시간 동안 발생한 순서대로 알림을 전달하기 위해 계속 시도합니다.

알림 전달을 다시 시도하는 전략은 시도 간 시간을 두 배로 늘리는 것입니다. 1분 간격에서 시작하여 매 12시간 동안 증가하여 72시간 동안 총 15번을 다시 시도합니다.

Webhook 수신자가 72시간 이내에 응답하지 못하고 지난 7일 동안 성공적인 알림 배달이 없는 경우 Webhook은 비활성화됩니다. Webhook이 다시 활성화될 때까지 이 URL에 알림이 전송되지 않습니다.

Webhook이 비활성화되는 시점과 나중에 다시 활성화되는 시점 사이의 모든 알림은 손실됩니다.

쉽고 빠르게 지원 받기

신규 사용자이신가요?

webhook 구성

개요

사용되는 방식

Webhook URL의 의도 확인

Webhook 알림에 응답하는 방법

1. HTTP 헤더 X-AdobeSign-ClientId 및 이 클라이언트 ID인 값

2. 키가 xAdobeSignClientId이고 값이 동일한 클라이언트 ID인 JSON 응답 본문

사전 요구 사항

Acrobat Sign Webhook 역할을 하는 Azure 함수 트리거를 만드는 단계

Acrobat Sign Webhook을 등록하는 논리 추가

옵션 1. X-AdobeSign-ClientId의 클라이언트 ID를 응답 헤더로 전달

옵션 2. xAdobeSignClientId 키를 사용하여 응답 본문에 클라이언트 ID 전달

사용 준비됨

AWS Lambda 함수 만들기

사례 1: X-AdobeSign-ClientId의 클라이언트 ID를 응답 헤더로 전달

사례 2: xAdobeSignClientId 키를 사용하여 응답 본문에 클라이언트 ID 전달

AWS API Gateway 구성

API 배포

사용 준비됨

구성 옵션

범위

URL

이벤트

계약:

대량 전송:

웹 양식:

라이브러리 템플릿(API만 해당):

알림 매개변수

양방향 SSL 인증

웹 서버 확인

클라이언트 인증서 확인

활성화하거나 비활성화하는 방법

Webhook 활성화

Webhook 비활성화

Webhook 보기 또는 편집

Webhook 삭제

우수 사례

주의 사항...

JSON 크기 제한

Webhook 알림

수신 대기 서비스가 다운되었을 때 다시 시도

쉽고 빠르게 지원 받기