APEX - Apex&.Net

Lightning Platform

1. metadata-driven architecture에 의존

코드, 설정, 앱을 포함한 모든 것들이 metadata로 지정됨

 

2. 데이터베이스와 긴밀하게 통합됨

User interface, security, reporting과 같은 모든 종류의 기능이 Platform에 바로 내장되어 있음.

이 통합을 통해 앱을 매우 빠르게 구축 가능.

 

3. node 설정이나 관리 작업, Upgrading, Tuning, Scaling에 대해 걱정할 필요 X

 

 

 

ASP.NET - Visualforce 유사점

• 코드에서 마크업이 명확하게 분리되어 있음
• Form field를 사용하여 컨트롤러에 정의된 속성에 코드 매핑
• HTTP가 stateless이기 때문에 Viewstate*가 ASP.NET과 마찬가지로 Visualforce에서도 골칫거리 (하지만 Viewstate 제한을 우회하는 방법 있음)

※ Viewstate : 페이지 자체를 포함하여 Web Forms 페이지의 각 컨트롤에는 기본 Control 컨트롤에서 상속된 ViewState 속성이 있음.

                             ASP.NET 페이지 프레임워크에서 페이지를 렌더링하기 직전에 페이지와 각 컨트롤 값을 자동으로 저장할 때 사용

 

 

 

 

Lightning Platform의 특징

 

 

Apex - Database의 긴밀한 결합

Class와 Standard object는 지속적으로 동기화됨

플랫폼은 이러한 종속성을 보장하기 위해 데이터베이스 스키마와 코드가 동기화되지 않도록 함.

-> Apex 코드에서 참조하는 Custom object/field를 삭제하려고 하면 플랫폼에서 오류 발생, 작업 허용 X

 

 

 

Unit Test 필수

Apex 코드를 Production org에 배포하려면 75%의 test coverage가 있어야 함

Unit test => 강력하고 오류 없는 코드의 개발 촉진, 모든 테스트가 주요 릴리즈 전에 실행되기 때문에 플랫폼의 안정성에 매우 중요

 

 

 

Solution, Project, Config file 없음

어플리케이션 만들 수 있지만 .NET application이나 assembly*를 만드는 것과는 다름

※ assembly : 버전 관리되고 배포되는 프로그램의 단위

 

Lightning Platform의 Application = Tab, Report, Dashboard, Page와 같은 Component의 loose collection

몇 가지는 세일즈포스 org에서 제공되며, Point-and-Click wizard를 통해 만들 수 O

AppExchange에서 타사에서 만든 앱 구매 O

 

모든 코드는 클라우드에 상주하고 실행됨

데이터베이스가 바로 구워지기 때문에 connection string 필요 X

ASP.NET MVC와 달리 route 구성 필요 X

 

 

 

훨씬 작은 Class Library

.NET Framework보다 훨씬 작기 때문에 Apex 더 쉽고 빠르게 사용 가능

완벽한 맞춤형 코딩 앱 구축할 때 => Heroku Enterprise 플랫폼

 

 

 

Development Tools

Developer Console 사용해 소스 코드 편집, 탐색, 디버깅, 문제 해결

 

 

 

보안 처리

Lightning Platform에서는 인증 또는 암호&Database connection string 저장에 대해 걱정할 필요 XID는 플랫폼에서 처리

다양한 레벨에서 데이터에 대한 액세스 제어

보안은 선언적으로 처리됨

 

 

 

Integration

Apex 사용하여 웹 서비스 만들고 노출, Apex에서 외부 웹서비스 호출 Oorg의 데이터에 대한 직접 액세스 제공하는 SOAP, REST API 모두 제공

.NET, Java, PHP, Objective C, Ruby, JavaScript 등 원하는 언어 사용 O

 

 

 

 

 

 

 

---

Execution Context

 

 

 

Execution Context란?
ASP.NET application의 경우 코드는 어플리케이션 도메인의 컨텍스트에서 실행됨
Lightning Platform에서 코드는 execution context 내에서 실행됨
이 context는 코드가 실행된 시점과 종료 시점 사이의 시간을 나타냄

 

 

 

Apex 호출 방법

Database Trigger	Custom/Standard object의 특정 이벤트에 대해 호출됨
Anonymous Apex	Dev Console, 기타 도구에서 즉시 실행되는 코드 스니펫
Asynchronous Apex	Future/queueable Apex 실행 / Batch job 실행 / Apex가 지정된 간격으로 실행되도록 예약할 때 발생
Web Services	SOAP/REST Web Service를 통해 노출되는 코드
Email Services	Inbound email을 처리하도록 설정된 코드
Visualforce / Lightning Pages	Visualforce controller & Lightning component는 자동으로 사용자가 버튼 클릭과 같은 작업을 시작할 때 Apex 코드 실행 O Lightning component는 Lightning process 및 Flow에서도 실행 O

 

 

 

 

Asynchronous Apex

 

비동기 Apex : 사용자가 작업이 끝날 때까지 기다릴 필요 없이 백그라운드에서 작업을 실행하는 프로세스 또는 함수
일반적으로 외부 시스템에 대한 호출, 더 높은 제한이 필요한 작업 및 특정 시간에 실행해야 하는 코드에 대해 Asynchronous Apex를 사용

 

 

언제 Asynchronous Apex를 사용해야 할까?

1. 많은 수의 레코드 처리할 때

• Asynchronous process와 관련된 limit은 Synchronous의 limit보다 높음
• 수천, 수백만 개의 레코드를 처리해야 하는 경우 Asynchronous process가 가장 좋음

2. 외부 웹 서비스에서 콜아웃할 때

• 콜아웃을 처리하는 데 시간이 오래 걸릴 수 있지만 Lightning Platform에서는 트리거가 콜아웃을 직접 만들 수 X

3. 더 나은, 빠른 사용자 경험을 만들 때

• 일부 프로세싱을 Asynchronous call로 오프로드하여 더 좋고 빠른 사용자 경험 만듦

 

 

Asynchronous process의 유형

• Future method
• Batch Apex
• Scheduled Apex

 

 

 

Future Method

웹서비스에 대한 콜아웃을 만들어야 하거나 간단한 처리를 비동기 작업으로 오프로드하려는 상황에서는 Future method를 만드는 것이 좋음

 

동기식 -> 비동기식 처리로 메소드 변경하는 방법

• 메소드에 @future 주석 추가
• 메소드가 static이고 void만 반환하는지 확인하기

Limitation

• Apex job ID가 반환되지 않으므로 execution 추적 불가
• 매개변수는 primitive 데이터 타입. 기본 데이터 타입의 array 또는 collection이어야 함.
• Future method는 object를 argument로 사용 X
• Future method를 연결하고, 다른 메소드 호출 불가

 

 

Batch / Scheduled Apex

일괄처리 인터페이스

Database.Batchable 인터페이스를 구현

start( ), execute( ), finish( ) 메소드 정의

Database.executeBatch 메소드 사용하여 Batch 클래스 호출 O

 

Batchable Limitation

• 문제 해결 어려울 수 있음
• Job이 대기열에 있으며 서버 가용성에 따라 달라지고, 예상보다 오래 걸릴 수 있음 

 

 

Queueable Apex

Queable Apex의 장점

1. Non-primitive types

클래스는 sObject 또는 custom Apex type과 같은 non-primitive data type의 parameter variable을 허용 O

 

2. Monitoring

Job을 submit하면 Job을 식별하고 진행 상황을 모니터링하는 데 사용할 수 있는 JobId가 반환됨

 

3. Chaining Jobs

실행 중인 job에서 두 번째 job을 시작하여 한 job을 다른 job으로 연결 O

연쇄 작업은 순차 처리에 유용함

 

 

 

 

Debug & 진단

Debug Log

System.debug('My Debug Message');

지정 가능한 Logging Level

• NONE
• ERROR
• WARN
• INFO
• DEBUG
• FINE
• FINER
• FINEST

이 Level은 Lowest에서 Highest로 실행되며 누적됨.

FINEST level을 선택하면 ERROR, WARN, INFO 등으로 기록되는 모든 메세지 받게 됨

 

 

각 Debug Log는 20MB 이하여야 함 (초과하면 모든 항목 표시 X)

각 org는 최대 1,000MB의 debug log 보유 O

가장 오래된 log를 덮어씀

 

 

 

 

 

 

출처 : http://jaee-h.tistory.com/entry/Apex-basic-03-ApexNet

참조 : Trailhead - Apex & .NET Basics