devrel-kr / nhn-toast-notification-service-custom-connector Goto Github PK

• #43
• ListMessage, SendMessage 2개 api에 대해서 응답 개체 만들기

1. 각 응답개체마다 header와 body 영역이 있는데, header 영역은 공통이고 body 영역만 다르게 생겼습니다.
2. 제네릭을 적절히 활용하시면 해결할 수 있습니다.
3. body 영역은 때로는 단일 개체 형식, 때로는 배열 형식이므로 이 역시도 제네릭을 적절히 활용하면 가능합니다.
4. nt-common 프로젝트와 nt-sms 프로젝트를 적절히 활용하세요.

• 4개 엔드포인트 각각에 해당하는 Query validator 를 만들어 보세요

  • ListSenders 엔드포인트에 붙여놓은 Query validator를 참조해 보세요.
  • RequestHeaderValidator 역시 참조해 보세요.
  • 필수 쿼리 파라미터가 없을 경우 BadRequest 예외를 발생시켜야 합니다.

• Query validator를 다 만들었다면 각 validator에 해당하는 단위테스트 코드도 만들어 보세요.

  • RequestHeaderValidator 단위테스트를 참조하세요.

Validator 클라스 안쪽에 들여다 보면 어떤 것들은 Regex 개체가 있습니다. 이 개체 의존성을 역전시켜야 합니다. 혹은 적어도 싱글톤으로 작동할 수 있게끔 해야 합니다.

블레이저 웹 어셈블리로 만들기

Requirements:

• 발송결과 다운로드 API

Requirements:

• 인증용/긴급용 SMS API

요구사항

• 현재 CI/CD 파이프라인에서는 단위테스트만 돌리고 있습니다.

  dotnet test . -c Release --filter:"TestCategory!=Integration"

• 향후 통합테스트 역시 한꺼번에 테스트 할 수 있게끔 필터를 조정해 주세요.

• 문자메시지를 실제로 보내는 API를 호출하는 테스트만 제외하고, 나머지는 모두 실제 API 호출을 하고 그 결과를 받아올 수 있어야 합니다.

아래 두 API 합친 BFF 만들기

• sms
• sms-verify

Requirements:

• 장문 MMS API

Requirement:

헬스체크에 필요한 /api/ping 엔드포인트를 추가합니다.

Approaches:

• 별도의 헬스체크용 프로젝트를 생성합니다.
• 헬스체크용 프로젝트는 /api/ping 엔드포인트를 포함합니다.
• 엔드포인트는 참조하는 모든 다른 애저 펑션앱에서 사용할 수 있게끔 재사용할 수 있어야 합니다.

Requirements:

• 첨부 파일 API

애플리케이션을 셋업하는 전체 프로세스는 아래와 같습니다.

1. main.bicep을 이용해서 Azure API Management와 Azure Functions 앱을 생성합니다.
2. Azure CLI의 az functionapp deploy ... 명령어를 이용해서 앱을 배포합니다.
3. provision-apiManagementApi.bicep을 이용해서 배포한 펑션앱과 API Management 앱을 연결시킵니다.

현재 지민님께서 완성하신 부분은 1번이구요, 이제 setup-apim.sh 파일을 생성하셔서 2번과 3번을 완성시키세요.

이 때, 2번을 수행하면서 필요한 아티팩트는 깃헙 API를 이용해서 최신 버전의 릴리즈를 찾아야 합니다. 그리고 그렇게 찾은 아티팩트의 URL을 이용해 배포하세요.

3번을 수행하면서는 az deployment group create ... 명령어를 이용해 URL을 지정해서 수행하게 하세요. 이 때 bicep 파일을 직접 활용할 수 없기 때문에 provision-apiManagementApi.bicep 파일을 provision-apiManagementApi.json 파일로 변환해야 합니다. 이미 이 부분은 리포지토리에 변환되어 있으니 그 파일을 활용하는 것으로 해서 진행하세요.

질문 있으시면 디스코드에 남겨주세요!

위 코드 스니펫을 보면 SMS와 SMS Verification 을 하드코딩해 두었습니다. 이걸 workflow_call 로 보낼 때 변수로 보내서 배열로 처리하게 할 수 있을까요? 그러면 앞으로 몇 개의 앱이 더 추가가 된다고 하더라도 최초 배열값만 수정하면 그 다음부터는 알아서 자동으로 될 것 같아요.

아니면 이걸 매트릭스로 처리할 수도 있을 것 같은데요, 그렇게 하면 배포 workflow_call 은 한번에 앱 하나만 배포하지만 matrix 로 루프 돌리면 원하는 숫자만큼 돌릴 수도 있을 것 같습니다.

Requirement:

• 현재 각 엔드포인트 안에서 일어나는 일련의 워크플로우를 Fluent API 형태로 정리할 것

Requriements:

• 발신번호 등록 API

-각 API 별로 응답 개체 만들기 #43
-GetMessage, ListMessageStatus 2개 api에 대해서 응답 개체 만들기

아래 두 URL을 APIM의 CORS 정책에 추가하기

• https://make.powerapps.com
• https://make.powerautomate.com

현재 Request URL 을 만드는 과정이 꽤 복잡합니다. 이를 리팩토링해 봅시다.

현재:

            var baseUrl = this._settings.BaseUrl;
            var version = this._settings.Version;
            var endpoint = this._settings.Endpoints.GetMessage;
            var options = new GetMessageRequestUrlOptions()
            {
                Version = version,
                AppKey = headers.AppKey,
                RequestId = requestId,
                RecipientSeq = int.TryParse(req.Query["recipientSeq"].ToString(), out int recipientSeqVal) ? recipientSeqVal : 0,
            };
            var requestUrl = this._settings.Formatter.Format($"{baseUrl.TrimEnd('/')}/{endpoint.TrimStart('/')}", options);

향후:

var requestUrl = new RequestUrlBuilder().WithSettings(settings).WithHeaders(headers).WithQueries(queries).Build();

추가로 RequestURL Builder 에 해당하는 단위테스트 역시도 함께 만들어야 합니다.

힌트:

1. RequestUrlBuilder 클라스를 만들고 그 안에 WithSettings(...), WithHeaders(...), WithQueries(...), Build() 메소드를 추가합니다.
2. DSL 형태의 Chained Method 를 활용해 봅니다.
3. Chained Method 를 위해서는 Extension Method 형식을 고려해 볼 수도 있습니다.

현재 모든 API 엔드포인트의 응답 개체 모양은 아래와 같습니다.

하지만 각각의 엔드포인트는 저마다 응답개체의 형식이 있습니다. 아래는 하나의 예시로서 GetMessage 엔드포인트의 응답개체 형식입니다.

{
   "header":{
      "resultCode":0,
      "resultMessage":"SUCCESS",
      "isSuccessful":true
   },
   "body":{
      "data":{
         "requestId":"20180810100630ReZQ6KZzAH0",
         "requestDate":"2018-08-10 10:06:30.0",
         "resultDate":"2018-08-10 10:06:42.0",
         "templateId":"TemplateId",
         "templateName":"템플릿명",
         "categoryId":0,
         "categoryName":"카테고리명",
         "body":"본문",
         "sendNo":"15446859",
         "countryCode":"82",
         "recipientNo":"01000000000",
         "msgStatus":"3",
         "msgStatusName":"성공",
         "resultCode":"1000",
         "resultCodeName":"성공",
         "telecomCode":10001,
         "telecomCodeName":"SKT",
         "recipientSeq":1,
         "sendType":"0",
         "messageType":"SMS",
         "userId":"tester",
         "adYn":"N",
         "resultMessage": "",
         "senderGroupingKey":"SenderGroupingKey",
         "recipientGroupingKey":"RecipientGroupingKey"
      }
   }
}

1. @KIMTHE @wlals761 두 분이 서로 두개씩 엔드포인트를 나눠서 응답 개체를 만들고 적용시켜 보세요.
2. 각 응답개체마다 header와 body 영역이 있는데, header 영역은 공통이고 body 영역만 다르게 생겼습니다.
3. 제네릭을 적절히 활용하시면 해결할 수 있습니다.
4. body 영역은 때로는 단일 개체 형식, 때로는 배열 형식이므로 이 역시도 제네릭을 적절히 활용하면 가능합니다.
5. nt-common 프로젝트와 nt-sms 프로젝트를 적절히 활용하세요.

주의사항:

• 이 이슈에 두 분은 각자 맡은 부분을 별도의 이슈로 만들고 연결시켜 주세요.
• 브랜치는 항상 feature/xxx 형태로 만들어서 작업해 주세요.