Jump to content
과거의 기술자료(읽기 전용): https://tech.devgear.co.kr ×
과거의 기술자료(읽기 전용): https://tech.devgear.co.kr

이 사이트 검색

검색 태그: 'rad 서버'.

  • 태그로 검색

    태그 사이를 쉼표(,)로 구분하세요.
  • 작성자로 검색

콘텐츠 유형


게시판

  • 엠바카데로 (Embarcadero) 개발도구: 델파이 (Delphi), C++빌더 (C++Builder), RAD 스튜디오 (RAD Studio)
    • [기술 Q&A 게시판] 델파이, C++빌더, RAD 스튜디오
    • [설치/등록 Q&A 게시판] 델파이, C++빌더, RAD 스튜디오
    • [기술 기고 게시판] 델파이, C++빌더, RAD 스튜디오
    • [포트폴리오 게시판] 내가 참여한 프로젝트/프로그램 소개
    • [구인 게시판] 개발자 채용/프로젝트 의뢰
  • 엠바카데로 (Embarcadero) DBMS: 인터베이스 (InterBase)
    • [기술 Q&A 게시판] 인터베이스
    • [설치/등록 Q&A 게시판] 인터베이스
    • [기술 기고 게시판] 인터베이스
  • 비주얼 스튜디오 (Visual Studio) 관련 도구
    • [기술 Q&A 게시판] 비주얼 어시스트
    • [설치/등록 Q&A 게시판] 비주얼 어시스트
    • [기술 기고 게시판] 비주얼 어시스트
  • 구록 (Gurock) 테스트도구: 테스트레일 (TestRail)
    • [기술 Q&A 게시판] 테스트레일
    • [설치/등록 Q&A 게시판] 테스트레일
    • [기술 기고 게시판] 테스트레일
  • 아이데라 (Idera) 데이터 도구: 아쿠아 데이터 스튜디오 (Aqua Data Studio), ER/Studio 등
    • ER스튜디오 (ER/Studio)
    • 아쿠아 데이터 스튜디오 (Aqua Data Studio)
  • API레이어 (Apilayer) 개발 도구: API레이어 (Apilayer)
    • [Q&A 게시판] API레이어 (Apilayer)
  • 엠바카데로 (Embarcadero) 라이선스 서버: ELC (Enterprise License Center)
    • [게시판] ELC (Enterprise License Center) 라이선스 서버
  • 이 사이트 이용 관련
    • [게시판] 이 사이트 관련 이용 팁과 Q&A

Categories

  • 이달의 기술자료: 엠바카데로
  • 비디오 세미나
    • UX Summit
    • DelphiCon
    • CodeRage
    • 데브기어 세미나
    • Skill Sprint
  • 기술백서(PDF)

Categories

  • 시작하기
  • 설치/등록/라이선스
  • 튜토리얼
  • 도서

Categories

  • RAD 스튜디오 역사관
  • 11 알렉산드리아
  • 10.4 시드니
  • 10.3 리오
  • 10.2 도쿄
  • 10.1 베를린
  • 10.0 시애틀
  • XE8~XE
  • 2010~6.0

...에서 결과 찾기

검색어 일치 조건


최초 작성일

  • Start

    End


최종 변경일

  • Start

    End


개수로 필터링...

가입

  • Start

    End


Group


자주 쓰는 도구

  1. 리자토 페르난도 (Rizzato Fernando)의 "Using FireDAC Connection Pooling with RAD Server" 를 번역했습니다. (원문 작성: 2022년 7월 19일, 최종 번역: 2022년 7월 20일) 연결 풀링 (connection pooling)이란? 연결 풀 (connection pool)이란 데이터베이스 연결(들)을 모아두어서 데이터베이스에 대한 요청(request)이 발생하면 재사용될 수 있도록 하는 캐시(cache)이다. 연결 풀 (connection pool)은 데이터베이스에서 명령을 수행하도록 할 때 그 성능 향상시키는 목적으로 사용된다. 사용자들이 각자 데이터베이스 연결을 열고(open) 유지하는 것은, 특히 데이터-중심 애플리케이션인 경우, 비용이 크고 자원(resource)가 낭비된다. 연결 풀링인 환경에서는, 연결이 한번 생성되면, 연결 풀 안에 위치하고 다시 사용될 수 있으므로 새 연결을 반드시 다시 만들어야 할 필요가 없어진다. 개발자는 연결 풀 하나에서 생성할 수 있는 최대 연결 수량을 정의할 수 있으므로, 필요한 데이터베이스 라이선스의 수량을 줄일 수 있다는 점에서도 관심을 가질 만하다. 이런 환경에서는, 연결 풀이 한도에 도달한 상태에서 새 요청이 도착하면, 연결 풀 안에 있는 연결들 중에서 아무것도 풀려서 사용할 수 있게 되지 않은 채 사전에 지정된 제한 시간에 도달하는 경우 해당 요청은 처리되지 못한다. 데이터베이스 연결이 제한 적인 연결 풀링에서는 사용자 수와 애플리케이션 아키텍처를 기반으로 해당 연결 풀에게 가장 이상적인 최대 연결 갯수를 지정하는 것이 중요한 열쇠이다. FireDAC 연결 풀링 (connection pooling)의 작동 방식 FireDAC에서 연결 풀링 (connection pooling)이 작동하는 방식은 상당히 쉬워서, 사용하는 연결의 프로퍼티(property) 하나만 설정하면 작동한다 (Pooled=True). 물론, 연결 풀링은 멀티-쓰레드 애플리케이션에서 더욱 빛난다. 짧은 작업(task) 여러개가 (거의) 동시에 실행되고, 각 작업마다 데이터베이스 연결이 있어야 하기 때문이다. 연결 풀링 기능을 사용할 때는, 해당 연결이 이미 만들어져 있고, 자신을 사용할 작업을 기다리고 있기 때문에, 작업 수행 시간이 훨씬 더 빠르고 자원 소모는 더 적다. 조금 더 수준 높게 활용하려면, "Pooled" 파라미터 뿐만 아니라, 아래 3 가지 파라미터까지도 고려해 볼 수 있다. 파라미터 설명 예시 POOL_CleanupTimeout POOL_ExpireTimeout 시간이 넘도록 사용되지 않는 연결을 FireDAC이 제거할 때까지의 시간이다. 기본값은 30000 밀리초 (30초)이다. 3600000 POOL_ExpireTimeout 연결이 사용되지 않은 채 여기에 지정한 시간 (밀리초)을 넘기면 연결 풀에서 지워지고 파괴될 수 있다. 기본값은 90000 밀리초 (90초)이다. 600000 POOL_MaximumItems 연결 풀 안에 들어갈 최대 연결 수량. 지정된 최대 수량보다 애플리케이션이 더 많은 연결이 필요하게 되는 시점이 되면 예외(exception)이 발생된다. 기본값은 50이다. 100 FireDAC에서는 (FireDAC의 .ini 파일 안에 저장되는) "영속(Persistent)" 연결, (애플리케이션의 해당 메모리에서만 사용할 수 있는) "프라이빗(Private)" 연결, (저장되지 않고, 이름도 없어서 FDManager가 관리하지 않는) "임시(Temporary)" 연결이 있다. 연결을 정의하고 설정하는 방법은 (연결 풀을 사용하든 않하든) 아래 도움말에 자세히 설명되어 있다. [DocWiki 번역] 연결을 정의하기 (FireDAC) Multithreading (FireDAC) FireDAC 연결 풀링 (connection pooling)을 RAD 서버 (EMS)에서 사용하기 진정한 백엔드 애플리케이션이라면, RAD 서버도 마찬가지로, 애플리케이션이 커가면서 늘어날 호출을 처리할 수 있는 풀링(pooling) 작동 방식은 거의 필수이다. 지금 보여 줄 예제에서는 FDManager를 통해 연결을 정의하는 "프라이빗(Private) 연결을 사용한다. 물론, FireDAC의 .ini 파일에 정의된 연결 역시 재사용할 수 있다. 더 나아가 FDManager를 통해 해당 .ini 파일을 적재하고 여기에 연결 풀링 파라미터를 추가할 수도 있다. 이렇게 연결 풀링은 서버 애플리케이션에만 적용되도록 할 수 있는데, 데스크탑 애플리케이션에서는 그다지 쓸 일이 없기 때문이다. 이 데모 앱은 RAD Server Wizard (https://docwiki.embarcadero.com/RADStudio/en/Creating_a_RAD_Server_Package) 를 사용하여 만들었으며, 최근에 추가된 EMSDataSetResource(https://docwiki.embarcadero.com/RADStudio/en/Using_RAD_Server_Components 그리고 https://blogs.embarcadero.com/using-emsdatasetresource-component-with-rad-server/)를 사용했다. 하지만, 직접 정의한 RAD 서버의 엔트포인트에도 똑같이 적용된다. 꼭 알아야 할 중요한 점은 애플리케이션 인스턴스 하나에는 FDManager 인스턴스가 하나만 존재할 수 있다는 점이다. 따라서 FDManager의 인스턴스는 해당 EMS 리소스의 initialization 구역 안에서 생성되어야 한다. 데모 프로젝트를 대상으로 부하(stress) 테스트 이 비디오는 연결 풀링 작동 방식을 설명하고, 이어서 JMeter를 사용하여 100 사용자의 부하를 테스트한다. 비디오 보기: https://blogs.embarcadero.com/using-firedac-connection-pooling-with-rad-server/#Running_a_stress_test_with_our_demo_project 추가 팁, RAD 서버 애플리케이션이 여러 패키지로 구성된 경우에도 풀링 메커니즘을 사용할 수 있다. FDManager에 의해 연결 풀링 구성을 정의하도록는 RAD 서버 리소스를 하나 생성하고 배포 환경에서 이 리소스가 가장 첫 번째 리소스로 적재( load)되도록 하기만 하면 된다.
  2. Emad Bin Abid 가 작성한 Everything You Need To Modernize With RAD Server (영문 원본 보기) 를 번역했습니다. 현대 사회에서 우리는 기술에 둘러싸여서 파묻혀있고 그 기술의 형태도 다양하다. 전적으로 클라우드 기반인 기술이 대부분이긴 하지만 여전히 상당 부분은 클라우드와 물리적인 하드웨어 컴퓨팅 장비가 함께 섞여 있기도 하다. 하지만 아무리 최신 기술이라도 결국은 더 최신 기술에 의해 밀려나고 시대에 뒤쳐지게 되는 때가 반드시 온다는 사실 하나는 분명하다. 모든 기술이 각자 급격하게 발전하지만, 결국 이런 발전된 기술이 제공하는 더 발전된 단계에 의해서 또는 문제를 해결하거나 서비스를 제공하는 방식 자체가 더 새롭고 강력한 그 무언가에 의해 교체되고 만다. 기술과 애플리케이션이 뒤안길로 사라지지 않도록 지키려면, 끊임없이 기능을 업드레이드하고 다가올 트렌드와 사용 방식을 예측하여 반영해야 한다. 단순 명쾌하다.그리고, 이 과정에서 어떤 작업은 매우 고될 수도 있다. 애플리케이션이 복잡하고 코드 기반이 너무 광범위한 경우에는 특히 그렇다. 또한 애플리케이션에서 사용된 많은 라이브러리와 프레임워크들 중에는 단종되거나, 쓸모없어지거나 업데이트가 필요한 것들도 있다. 애플리케이션을 업그레이드하고 현대화하는 어려움을 극복하려면, RAD 서버와 같이 그 과정을 세련되게 진행할 수 있는 강력한 수단을 제공하는 견고한 개발 솔루션이 필요하다. 우리는 이런 수단을 통해서 변경을 어떻게 해낼 것인 지에 대한 감을 잡을 수 있다. 그리고 이런 수단들 자체가 직접 현대화 작업 자체를 가이드하는 역할을 하기도 한다. 이 글은 RAD 서버를 사용하여 현대화 하는 것이 어떤 것인지 왜 애플리케이션에서 필수 요소이고 최우선으로 고려해야 하는 지를 들여다 본다. 애플리케이션을 현대화 해야하는 이유는? 불과 5년 전과 비교해도, 소프트웨어 개발 분야는 상당히 달라졌다. 운영체제의 추상화와 지원 능력이 발전함에 따라 애플리케이션은 하드웨어 장비의 리소스를 훨씬 더 효율적으로 사용한다. 컴포넌트 생태계가 풍부해 지고, 개발 도구 업계가 더 성숙해졌고, 프로그래밍 언어의 범위도 넓어짐에 따라 애플리케이션이 복잡한 처리를 이전보다 더 잘 수행할 수 있도록 하는 코드를 구현하는 과정 역시 더 최적화되었다. 이런 환경에서 우리의 애플리케이션이 살아남기 위해서는, 현대화를 해야 하고, 이전보다 더 많은 서비스를 제공해야 한다. 웹 애플리케이션 개발을 살펴보면, 웹 브라우저와 그 렌더링 능력이 발전함에 따라 웹 애플리케이션은 훨씬 더 동적이고 견고해졌다. 웹 애플리케이션을 개발 속도 역시 엄청나게 빨라졌다. 또한 화면 렌더링 측면에서는 반응형 UI 기술이, 그리고 장비의 센서 활용 면에서는 여러 하드웨어 센서와 기능의 최소한의 공통 분모를 다룰 수 있는 속성과 메소드를 제공하는 API와 같은 기술이 나온 덕분에, 제대로 만든 웹 애플리케이션이라면 모든 장비에서 사용할 수 있다. 모듈화는 마이크로서비스를 통해 실현되었고, 서버리스(Serverless)를 통해 운영 경제성까지 갖추었다. 보안성과 확장성 역시 애플리케이션 개발과 관련하여 매우 중요한 요소가 되었다. 사이버 공격이 증가함에 따라, 애플리케이션은 모든 면에서 보안성이 확보해야 하고, 관련된 베스트 프랙티스 (가장 좋다고 검증된 조치법)를 반영해야 한다. 또한 애플리케이션의 확장성을 확보하여 많은 사용자를 품을 수 있고 필요할 때 바로 사용될 수 있어야 한다. 이런 것들이 없이는 경쟁에서 밀리고 결국 잊혀지게 될 수도 있다. RAD 서버는 무엇인가? 어디에 사용되는가? RAD 서버는 현재 백-엔드 개발 애플리케이션 분야에서 앞서가는 솔루션 중 하나로서, 애플리케이션 서비스를 구축하고 배포할 수 있도록 하는 플랫폼이다. 여러 뛰어난 장점들을 갖추고 있으며 특히 백-엔드를 구축하려고 마음 먹으면 RAD 서버를 사용하여 바로 시작할 수 있다. API를 개발하고 애플리케이션을 서비스 하는데 필요한 기능 대부분이 이미 준비되어 있기 때문에 백-엔드 서버 전체를 맨 처음부터 시작하지 않아도 된다. 필요한 외부의 서버와 서비스는 RAD 서버를 통해 손쉽게 연결할 수 있다. MySQL, 오라클, SQL 서버, 인터베이스(Interbase) 등 거의 모든 엔터프라이즈 데이터베이스 기술에 연결할 수 있다. RAD 서버에는 사용자 관리 서비스, 디렉토리 서비스 등의 중요한 백-엔드 기능이 이미 들어 있다. 특히 정기적으로 솔루션을 개발하고 재배포하는 소프트웨어 제조사에게는 가장 도움이 되는 도구가 될 것이다. RAD 서버를 사용하면 REST API와 해당 엔드포인트를 작성, 공개, 관리를 빠르게 할 수 있다. 더 나아가 API 분석 기능, 성능과 이슈 모니터링 등의 기능이 내장되어 있어서 바로 사용하면 된다. 또한 사용자 관리, 그룹관리, 접근 제어를 할 수 있는 관리 포털도 제공된다 RAD 서버를 사용하여 애플리케이션을 현대화하는 방법은? RAD 서버에 내장되어서 바로 쓸 수 있는 백-엔드 개발과 플랫폼 모니터링 기능은 제쳐두고, 기존의 델파이와 C++빌더로 만든 기존의 클라이언트/서버에 있는 비즈니스 로직을 RAD 서버를 통해 어떻게 현대화 할 수 있는 지를 살펴보자. RAD 서버를 사용하면 기존의 애플리케이션 로직을 보안성과 확장성이 높은 서비스 기반 아키텍처로 손쉽게 마이그레이션 할 수 있다. 서비스 기반 아키텍처는 애플리케이션이 원활하게 작동할 수 있도록 하기 위해 서비스가 필요한 애플리케이션 구성 요소에게 해당 서비스를 제공하는 것에 촛점을 맞춘다. 애플리케이션이 일단 RAD 서버로 옮겨서 현대화되고 나면, 많은 이점을 누릴 수 있으며 이전보다 훨씬 많은 것을 제공할 수 있다. 전용 관리 콘솔, 배포 간편, 내장된 통계 콘솔 역시 RAD 서버의 장점이다. 또한 마이그레이션된 기존의 비즈니스 로직을 서비스하는 엔드포인트를 생성하고 관리할 수 있다. RAD 서버를 사용하여 현대화를 하면 다음과 같은 장점들 역시 갖출 수 있다. 클라우드 서비스 연결 능력: 거의 모든 기술 분야에서 클라우드 컴퓨팅과 여기에 연결하는 능력이 생존을 결정하게 될 미래가 빠르게 다가오고 있다. RAD 서버를 사용하면 구글, 아마존, 등등 대표적인 클라우드 플랫폼에서 제공하는 REST 클라우드 서비스를 수용할 수 있다. 도커(Docker)를 견고하게 지원: 컨테이너 기술은 최근의 소프트웨어 개발 산업에서 가장 큰 혁신이다. 그 중에서도 도커(Docker)는 거의 모든 곳에서 사용되는 지배적인 컨테이너 서비스이다. RAD 서버를 사용하면 도커 이미지를 만들고 도커 허브 (Docker Hub)에 올려둘 수 있어서 구글 클라우드, 마이크로소프트 애저, AWS로 간단하게 배포할 수 있다. 사물인터넷 장비 연결 능력: 사물인터넷은 강력한 네트워크 그리고 속도가 빠른 데이터 전송 환경을 바탕으로 하는 멋진 기술이다. 사물인터넷을 지원하는 장비는 필요한 애플리케이션과 바로 연결되어 작동할 수 있다. RAD 서버를 사용하면, 사물인터넷 장비를 여러분의 애플리케이션 서비스에 손쉽게 연결할 수 있다. 위 기능들은 오늘날의 디지털 시대의 첨단 기술이다. RAD 서버로 마이그레이션을 하면, 이제 여러분도 이런 첨단 기능을 갖출 수 있으며 서비스 기반 접근을 반영할 수 있다. RAD 서버의 능력을 살펴볼 수 있는 사례는? 초창기의 RAD 서버는 가장 먼저나온 백-엔드 개발 플랫폼은 아니지만, 그 서비스와 기능을 통해서 백-엔드의 기준을 세웠다. 많은 기업과 개발자들이 비즈니스 로직 처리를 담당하는 백-엔드 서비스를 제공하는 견고한 애플리케이션을 만들기 위해 RAD 서버를 사용해오고 있다. RAD 서버를 활용하는 아래의 프로젝트를 보면, 여러분이 바랬던 어플리케이션이 어떤 모습일지에 대해좋은 아이디어를 얻을 수 있을 것이다. 아래 내용은 RAD 스튜디오에 들어있는 예제들이다. RAD 서버가 애플리케이션에 어떻게 생명을 주는 지를 볼 수 있다. RAD 서버 멀티-테넌시 예제: 일반적인 소매점을 위한 예제이다. 여기에는 EMS(enterprise management system)을 활용하며, 파이어닥(FireDAC) 컴포넌트를 사용하여 데이터베이스에 연결한다. 또한 RAD 서버 콘솔을 통해 엔드포인트의 갯수와 사용 빈도 등의 통계를 보는 기능도 볼 수 있다. RAD 서버 파이어닥(FireDAC) 리소스 예제: 파이어닥(FireDAC)은 델파이에서 데이터를 연결할 때 사용하는 컴포넌트 세트로써 엔터프라이즈 데이터베이스 연결 속도가 빠르다. 이 예제는 EMS서버와 여기에 연결하는 클라이언트를 만드는 프로젝트이며, 파이어닥(FireDAC)을 사용하여 SQLite 데이터베이스에 연결한다. RAD 서버 콘솔은 별도로 하고, 이 예제의 EMS 서버는 RAD 서버 엔진을 기반으로 작동한다. 따라서, 해당 서버 호스트를 클라우드에 둘 수도 있고, 온프레미스에 둘 수도 있다. 위 예제와 별개로, 이와 비슷하게 RAD 서버를 충분히 활용하는 사례 템플릿들도 있고 원하면 가져다 쓸 수도 있다. 예를 들어, RAD 서버 간호사실(RAD Server Nurses Station) 템플릿은 병원/의원에서 환자 데이터를 자동으로 수집하는 기능이 구현되어 있다. 이 템플릿에는 사용자 관리, 데이터 수집과 배포, 알림 서비스 등 RAD 서버가 이미 내장하고 있는 기본 기능들도 사용하고 있다. 또한 다른 시스템이 연결할 때 REST HIPPA(미국의 개인의료 정보 보호 규정) 연결을 활성화하는 기능도 있다. 당신의 델파이 애플리케이션을 현대화하고 마이그레이션 할 준비가 되었다면, RAD 서버를 살펴보자. 어떻게 활용하면 원하는 목적을 이룰 수 있는 지를 알 수 있다.
  3. Kori

    10.2 도쿄 RAD 서버

    << 위로 이동 (최신 버전 포함 모든 버전) RAD 스튜디오 10.2 도쿄 "새 기능 한글 요약본: RAD 서버" 입니다. 모든 새 기능, 강화된 기능, 버그 픽스 등에 대해서는 Docwiki의 What's New 10.2 (영문 보기, 한글번역 보기) 와 관련 페이지를 보기 바랍니다. 10.2 도쿄 - RAD 서버 관련 주요 업데이트 요약 [10.2] RAD 서버 싱글 사이트 라이선스 제공 [10.2] RAD 서버 싱글 사이트 라이선스 제공 10.2.2에서 RAD 서버 싱글 사이트 라이선스를 제공합니다.(RAD 스튜디오, 델파이, C++빌더 엔터프라이즈 및 아키텍트 에디션에만 포함) RAD 서버는 즉시 사용가능한 턴키방식의 미들웨어 서버입니다. 주요 기능으로 범용적인 REST API 개발해 서비스 할 수 있으며, 엔터프라이즈 데이터베이스 제공, 통합 미들웨어 역할 수행, IoT 엣지웨어(사물인터넷 정보 수집) 등의 기능과 서비스를 모니터링 및 관리할 수 있는 웹 콘솔 서비스를 제공합니다. 자세히 보기: https://tech.devgear.co.kr/delphi_news/438369
  4. Kori

    10.3 리오 RAD 서버

    RAD 스튜디오 10.3 리오 "새 기능 한글 요약본: RAD 서버" 입니다. 모든 새 기능, 강화된 기능, 버그 픽스 등에 대해서는 Docwiki의 What's New 10.3 (영문 보기, 한글번역 보기) 와 관련 페이지를 보기 바랍니다. 10.3 리오 - RAD 서버 관련 주요 업데이트 요약 [10.3.3] RAD서버 도커(Docker) 배포 기능 제공 [10.3.2] 새로운 RAD서버 관리 콘솔 재설계한 RAD서버 콘솔 UI 엔드포인트 메소드와 Content-Type, Accept 연동 특성 추가 커스텀 메소드와 HTTP 메소드 연결 특성 추가 요청 처리를 클래스 또는 컴포넌트로 위임 JSON 처리를 위한 헬퍼 컴포넌트 추가 [10.3.3] RAD서버 도커(Docker) 배포 기능 제공 기본 제공되는 스크립트로 RAD서버 도커(Docker)를 배포하고 구성할 수 있는 기능이 제공됩니다. 도커 허브(Docker Hub)에서 호스팅되는 리눅스의 RAD서버용 도커 이미지도 제공됩니다. 바로 사용할 수 있는 형태입니다! 이제 도커에서 RAD서버를 배포하는 작업이 정말 간편해집니다. 자세히 보기: https://tech.devgear.co.kr/delphi_news/457810 [10.3.2] 새로운 RAD서버 관리 콘솔 새로운 기능면에서, UI와 사용 기능상의 업그레이드 외에도 REST 디버거 통합 버전이 제공된다는 점이 가장 획기적입니다. 이제 특정 RAD 서버 인스턴스에서 사용가능한 엔드포인트를 리스트로 정리하여 볼 수 있습니다. 자세히 보기: https://tech.devgear.co.kr/delphi_news/455346 재설계한 RAD서버 콘솔 UI RAD서버 콘솔 UI가 변경되었습니다. 이제 RAD서버 API 분석을 한 눈에 확인할 수 있고, Ext JS 프레임워크로 마이그레이션 할 수도 있습니다. 또한 RAD서버 푸시 알림이 더 많은 디바이스에 지원됩니다. 추가 분석 데이터에 대한 지원도 제공됩니다. 이 기능은 IDE의 겟잇 패키지 매니저(GetIt Package Manager)를 통해 다운로드 받아 사용할 수 있습니다. 엔드포인트 메소드와 Content-Type, Accept 연동 특성 추가 커스텀 리소스에 요청 시 URL과 HTTP 메소드에만 의존하지 않고, HTTP 해더의 Accept 및 Cotnet-Type에 따라 엔드 포인트 메소드를 연결하는 특성이 추가되었습니다. 이제 동일한 URL 및 HTTP 메소드라도 Accept 및 Content-Type에 따라 다른 동작을 구현할 수 있습니다. EndpointProduce : GET 메소드의 엔드 포인트에 추가할 수 있습니다. HTTP 해더의 Accept 항목 값과 일치하는 MIME 타입/파일 확장자를 파라메터로 지정합니다. EndpointConsume : PUT / POST / PATCH 메소드의 엔드 포인트에 추가할 수 있습니다. HTTP 해더의 Content-Type 항목 값과 일치하는 MIME 타입/파일 확장자를 파라메터로 지정합니다. 커스텀 메소드와 HTTP 메소드 연결 특성 추가 RAD 서버의 이전 버전에서는 HTTP 메소드(GET, POST 등)의 엔드 포인트 메소드 이름과 매핑되었습니다. 이제 위 방식 외에도 다른이름의 메소드를 엔드 포인트 메소드로 매핑할 수 있는 EndpointMethod 특성이 추가되었습니다. 요청 처리를 클래스 또는 컴포넌트로 위임 RAD 서버의 사용자 리소스에 발생한 요청을 필드로 지정한 다른 자원 모듈(클래스 / 컴포넌트)로 위임하는 기능이 추가되었습니다. 위임받는 클래스는 IEMSEndpointPublisher 인터페이스를 구현해야 합니다. JSON 처리를 위한 헬퍼 컴포넌트 추가 컴포넌트에 요청 처리를 위임하는 새로운 기능을 이용해 RAD 스튜디오 10.3 리오에서 JSON 처리를 단순화 하는 새로운 컴포넌트가 추가되었습니다. TEMSFileResource: 경로 및 파일이름 속성에 지정된 파일로 요청 처리 TEMDDataSetResource: DataSet 속성에 설정된 데이터셋의 데이터를 JSON으로 처리, 페이징 파라메터 지원
  5. 험프리

    11.0 알렉산드리아 RTL과 데이터

    << 위로 이동 (최신 버전 포함 모든 버전) RAD 스튜디오 11.0 알렉산드리아 "새 기능 한글 요약본: RTL과 데이터" 입니다. 11.0 알렉산드리아의 모든 새 기능, 강화된 기능, 버그 픽스 등에 대해서는 Docwiki의 What's New (영문 보기, 한글번역 보기) 와 관련 페이지를 보기 바랍니다. 11.0 알렉산드리아 - RTL과 데이터 관련 주요 업데이트 요약 플랫폼 식별자 RTL: TZipFile RTL 대용량 데이터 구조 개선 새로운 레코드 헬퍼 블루투스와 BLE 개선 추가 RTL 개선사항 제네릭 콜렉션 개선사항 RTTI PPL 스트림 날짜를 문자료 변환 인터페이스 인스턴스 생성 TNoRefCountObject 최적화 및 기타 JSON UTF8ToString 변경 사항 FireDAC Internet, HTTP 및 REST 클라이언트 라이브러리 인터넷 서버 기술 웹브로커 RAD 서버 데이터스냅 플랫폼 식별자 RTL은 macOS/Arm64 플랫폼용으로 새로운 플랫폼 식별자인 pidOSXArm64를 추가되었다. 기존 pidAndroid32Arm 및 pidAndroid64Arm 식별자는 새로운 pidAndroidArm32 및 pidAndroidArm64로 대체되었다. 모든 플랫폼 관련 식별자는 컴파일러의 동일한 형식과 순서를 사용합니다. <플랫폼 이름><아키텍처 이름><비트니스> RTL: TZipFile ZIP 파일(RTL의 TZipFile 클래스)의 품질 개선 및 최적화에 중점을 두었다. Zip64에 대한 지원과 TZipFile에서 파일을 제거하는 방법이 추가되었다. TZipHeader에서 GetFIleName 메서드를 지원하고 TZipFile.IsValid()는 스트림 매개 변수를 허용하며 System.Zip은 4GB보다 큰 파일에서도 작동한다. RTL 대용량 데이터 구조 개선 64비트 컴파일러에서 더 큰 메모리 구조에 대해 적절한 데이터 유형을 사용하도록 개선되었다. 예를 들어, 64비트의 TMemoryStream은 2GB보다 큰 데이터 구조를 지원한다. 이와 관련하여 새로운 메서드 TThread.GetTickCount64가 추가되었다(32비트 값을 반환하는 기존 TThread.GetTickCount는 호환성을 위해 RTL에 남아 있음) 새 레코드 헬퍼 추가 TDateTime을 위한 새로운 레코드 헬퍼: System.DateUtils 유닛에 “UTC Now”(실제 NowUTC를 호출) 등이 포함되었다. Currency타입을 위한 새로운 레코드 헬퍼: System.SysUtils 유닛에 TCurrencyHelper가 추가되었다 블루투스와 BLE 개선 클래식 블루투스 및 블루투스LE와 대부분의 플랫폼이 포함해 개선되었다. 특히 Windows 10 및 안드로이드(iOS 및 macOS도 포함)에 중점을 두었으며, 개선 사항에는 비콘 지원도 포함되었다. 추가 RTL 개선사항 제네릭 콜렉션 개선사항 일부 제네릭 유형에서 사용했던 TValue 심볼릭 이름이 RTL의 TValue와 혼돈되므로 다른 이름으로 변경됨.(TKey > K, TValue > V 등) 내부적인 변경으로 기존 코드에는 영향이 없다. 또한, 다음 코드와 같이 컬랙션 클래스의 추가 생성자가 없으며, array of value 형식의 파라메터로 대체되었다. procedure DoCheckStateChanged(Node: TTreeNode; CheckState: TNodeCheckState);virtual; constructor TList<T>.Create(const Values: array of T); constructor TDictionary<TKey, TValue>.Create(const AItems: array of TPair<TKey, TValue>); TDictionary는 Capacity, GrowThreshold와 해싱 구현이 개선되어 성능/메모리 사용량/충돌 최소화하며 균형잡힌 성능을 발휘한다. 내부적으로 구현에 사용된 TListHelper를 제거하고 강력한 타입인 TArray<T>를 사용해 스트리밍과 데이터 매핑 코드 관련된 모든 항목이 업데이트 되었다. RTTI RTTI에 대한 개방형 배열 지원: RTTI를 통해 개방형 배열 매개변수가 있는 메서드 호출을 허용하고 TVirtualMethodInterceptor에서 개방형 배열 인수도 지원힌다. TValue는 TDateTime에 대한 지원이 추가되며, TValue 및 Variant 유형 교환이 개선되었다. PPL (병렬 프로그래밍 라이브러리) PPL 스레드 풀 통계에 더 쉽게 액세스할 수 있도록, TThreadPoolStats.Get 메서드가 이제 공개되었다. 스트림 새로운 TPointerStream 클래스를 사용하면 포인터 위치와 크기를 표시하여 TStream 인터페이스를 사용하여 메모리 내 데이터를 읽고 쓸 수 있다. TStream.CopyFrom에는 알 수 없는 크기가 필요하지 않으며, 이 방법은 Count가 큰 경우에도 최적화되었다(최대 400% 개선). 날짜를 문자료 변환 날짜를 문자로 변환과 반대로 변환이 개선되었다. 참고로, StrToDate는 ‘to date’ 형식 문자열을 엄격히 따르고, 월과 일 이름이 있는 날짜 형식을 지원하며, 내부에 임의의 텍스트가 있는 날짜 형식도 지원한다. 또한, TFormatSettings 날짜/시간 관련 속성 초기화를 개선해 모든 플랫폼에서 표현이 통합되었다. 인터페이스 인스턴스 생성 새로운 System.Generics.Defaults._MakeInterfaceInstance 이용 인터페이스 인스턴스를 만들 수 있고, 모든 인터페이스 메소드는 익명 메소드로 표시된다. TNoRefCountObject 새로운 클래스 System.TNoRefCountObject는 참조 카운트가 IInterface 구현이다.(오래되고 모호한 TSingletonObject를 대체) 최적화 및 기타 최적화된 _FinalizeRecord 및 _FinalizeArray 레거시 TDatamodule.OldCreateOrder 속성이 제거 되고 기본값 True로 인식. 해당 속성이 폼파일에 있는 경우 무시됨(오류 미발생). 델파이 초기 버전 생성 순서 로직과 호환성을 위해 사용 된 항목 향상된 파스칼 System.Pos TArray<T>.BinarySearch 최적화 TList<T>.Sort( ..., Index, Count ) overload 추가 System.IOUtils.TFile.Size 추가 ClassParent 및 InitInstance에 대한 TObject 성능 수정 System.IOUtils.TPath에 대한 몇 가지 개선 사항 RTL에서 260자 보다 긴 시스템 경로 지원, (최신 버전의 Windows 등)운영체제에서 지원하는 경우 클래스 속성 TThread.OnSynchronize 추가 EInOutError 및 EInOutArgumentException 메시지에 경로가 포함되고 경로 필드를 갖음 성능 향상 _UInt32ToHexString 및 _UInt64ToHexString TSingleHelper 및 TDoubleHelper용 Parse 및 TryParse TGUID 데이터 구조는 이제 System.pas에서만 정의됨 JSON ParseJSONValue()를 TJSONObject에서 TJSONValue로 이동 Integer에 대해 TJSONObject.AddPair(overload) 추가 UTF8ToString 변경 사항 array of AnsiChar을 허용하는 UTF8ToString 오버로드가 제거되고 UTF8ToString(array of Byte) 지원중단 됨. 제거된 함수: UTF8ToString(const S: _PAnsiChr) 해결 방법 은 System.UTF8ToString 참조 FireDAC PostgreSQL 드라이버는 PostgreSQL v13 지원, PostgreSQL 저장 프로시저 지원 포함 Oracle 19c 및 Oracle 저장 프로시저에 대한 128자 매개변수 이름에 대한 공식 지원 TFDSortOption에 soDigitsAsNumbers 확장, System.SysUtils의 TCompareOption과 유사 FireDAC 모니터 UI 개선 /bin 하위 폴더가 아닌 VendorHome에서 드라이버를 찾도록 Firebird 드라이버를 개선(이전 버전의 Firebird에는 정확함). Internet, HTTP 및 REST 클라이언트 라이브러리 백엔드 및 EMS 클라이언트 구성 요소에 대한 타임아웃 메커니즘: TEMSProvider, TKinveyProvider, TParseProvider 클래스는 2가지 새로운 속성: ConnectTimeout, ReadTimeout TEMSApi.TConnectionInfo, TParseApi.TConnectionInfo, TKinveyApi.TConnectionInfo: ConnectTimeout 및 ReadTimeout 변수 TDSRestConnection은 ConnectionTimeOut 표시 HTTP / 2에 대한 Windows 지원 추가 THttpClient.ProtocolVersion 신규 속성 TNetHttpClient.ProtocolVersion 신규 속성 새로운 TBase64URLEncoding 인코딩 및 TNetEncoding.Base64URL 속성 모든 플랫폼에 대해 전체 RTL에서 gethostbyname를 getaddrinfo로 전환 새로운 TCertificate.PublicKey, 공개 키 모듈 포함 ContentType은 이제 문자열 유형, 열거형이 아님 . 이로서 하나의 콘텐츠 타입 문자열 사용 가능. 또한 새로운 RestRequest의 CustomContentType Windows용 TNetHTTPClient에서 TLS 1.3 지원 TSocket에 대한 여러 개선 사항 새로운 TRESTRequestDataSetAdapter 컴포넌트는 JSON을 통해 TDataSet(예: TFDMemTable) 데이터를 서버에 업로드하는 작업 단순화. 서버 측에서 TRESTResponseDataSetAdapter REST 구성 요소의 동반자 TRestClient 구성 요소는 기본 HTTPClient 구성 요소의 SecureFailureReasons 속성을 표시함 Vcl.Styles 유닛에서 이제 TCustomStyle 클래스 FCustomElements 및 FSource가 protected 섹션에 선언됨 인터넷 서버 기술 웹브로커 ISAPI DLL 스레드에는 Web.Win.ISAPIThreadPool.StackSize 변수를 사용하여 구성 가능한 StackSize 제공. 2GB(MaxInt)보다 큰 파일을 전송/스트리밍할 때 WebBroker 성능 대폭 향상 RAD 서버 RAD 서버를 위한 Multipart/form-data 지원 데이터스냅 (DataSnap) 데이터스냅: REST URI는 이제 TDSMethodMapEvent 이벤트를 기반으로 하는 새로운 메커니즘을 사용해 구성할 수 있다.
  6. << 위로 이동 (최신 버전 포함 모든 버전) RAD 스튜디오 11.0 알렉산드리아 "새 기능 한글 요약본: RTL과 데이터" 입니다. 11.0 알렉산드리아의 모든 새 기능, 강화된 기능, 버그 픽스 등에 대해서는 Docwiki의 What's New (영문 보기, 한글번역 보기) 와 관련 페이지를 보기 바랍니다. 11.0 알렉산드리아 - RTL과 데이터 관련 주요 업데이트 요약 플랫폼 식별자 RTL: TZipFile RTL 대용량 데이터 구조 개선 새로운 레코드 헬퍼 블루투스와 BLE 개선 추가 RTL 개선사항 제네릭 콜렉션 개선사항 RTTI PPL 스트림 날짜를 문자료 변환 인터페이스 인스턴스 생성 TNoRefCountObject 최적화 및 기타 JSON UTF8ToString 변경 사항 FireDAC Internet, HTTP 및 REST 클라이언트 라이브러리 인터넷 서버 기술 웹브로커 RAD 서버 데이터스냅 플랫폼 식별자 RTL은 macOS/Arm64 플랫폼용으로 새로운 플랫폼 식별자인 pidOSXArm64를 추가되었다. 기존 pidAndroid32Arm 및 pidAndroid64Arm 식별자는 새로운 pidAndroidArm32 및 pidAndroidArm64로 대체되었다. 모든 플랫폼 관련 식별자는 컴파일러의 동일한 형식과 순서를 사용합니다. <플랫폼 이름><아키텍처 이름><비트니스> RTL: TZipFile ZIP 파일(RTL의 TZipFile 클래스)의 품질 개선 및 최적화에 중점을 두었다. Zip64에 대한 지원과 TZipFile에서 파일을 제거하는 방법이 추가되었다. TZipHeader에서 GetFIleName 메서드를 지원하고 TZipFile.IsValid()는 스트림 매개 변수를 허용하며 System.Zip은 4GB보다 큰 파일에서도 작동한다. RTL 대용량 데이터 구조 개선 64비트 컴파일러에서 더 큰 메모리 구조에 대해 적절한 데이터 유형을 사용하도록 개선되었다. 예를 들어, 64비트의 TMemoryStream은 2GB보다 큰 데이터 구조를 지원한다. 이와 관련하여 새로운 메서드 TThread.GetTickCount64가 추가되었다(32비트 값을 반환하는 기존 TThread.GetTickCount는 호환성을 위해 RTL에 남아 있음) 새 레코드 헬퍼 추가 TDateTime을 위한 새로운 레코드 헬퍼: System.DateUtils 유닛에 “UTC Now”(실제 NowUTC를 호출) 등이 포함되었다. Currency타입을 위한 새로운 레코드 헬퍼: System.SysUtils 유닛에 TCurrencyHelper가 추가되었다 블루투스와 BLE 개선 클래식 블루투스 및 블루투스LE와 대부분의 플랫폼이 포함해 개선되었다. 특히 Windows 10 및 안드로이드(iOS 및 macOS도 포함)에 중점을 두었으며, 개선 사항에는 비콘 지원도 포함되었다. 추가 RTL 개선사항 제네릭 콜렉션 개선사항 일부 제네릭 유형에서 사용했던 TValue 심볼릭 이름이 RTL의 TValue와 혼돈되므로 다른 이름으로 변경됨.(TKey > K, TValue > V 등) 내부적인 변경으로 기존 코드에는 영향이 없다. 또한, 다음 코드와 같이 컬랙션 클래스의 추가 생성자가 없으며, array of value 형식의 파라메터로 대체되었다. procedure DoCheckStateChanged(Node: TTreeNode; CheckState: TNodeCheckState);virtual; constructor TList<T>.Create(const Values: array of T); constructor TDictionary<TKey, TValue>.Create(const AItems: array of TPair<TKey, TValue>); TDictionary는 Capacity, GrowThreshold와 해싱 구현이 개선되어 성능/메모리 사용량/충돌 최소화하며 균형잡힌 성능을 발휘한다. 내부적으로 구현에 사용된 TListHelper를 제거하고 강력한 타입인 TArray<T>를 사용해 스트리밍과 데이터 매핑 코드 관련된 모든 항목이 업데이트 되었다. RTTI RTTI에 대한 개방형 배열 지원: RTTI를 통해 개방형 배열 매개변수가 있는 메서드 호출을 허용하고 TVirtualMethodInterceptor에서 개방형 배열 인수도 지원힌다. TValue는 TDateTime에 대한 지원이 추가되며, TValue 및 Variant 유형 교환이 개선되었다. PPL (병렬 프로그래밍 라이브러리) PPL 스레드 풀 통계에 더 쉽게 액세스할 수 있도록, TThreadPoolStats.Get 메서드가 이제 공개되었다. 스트림 새로운 TPointerStream 클래스를 사용하면 포인터 위치와 크기를 표시하여 TStream 인터페이스를 사용하여 메모리 내 데이터를 읽고 쓸 수 있다. TStream.CopyFrom에는 알 수 없는 크기가 필요하지 않으며, 이 방법은 Count가 큰 경우에도 최적화되었다(최대 400% 개선). 날짜를 문자료 변환 날짜를 문자로 변환과 반대로 변환이 개선되었다. 참고로, StrToDate는 ‘to date’ 형식 문자열을 엄격히 따르고, 월과 일 이름이 있는 날짜 형식을 지원하며, 내부에 임의의 텍스트가 있는 날짜 형식도 지원한다. 또한, TFormatSettings 날짜/시간 관련 속성 초기화를 개선해 모든 플랫폼에서 표현이 통합되었다. 인터페이스 인스턴스 생성 새로운 System.Generics.Defaults._MakeInterfaceInstance 이용 인터페이스 인스턴스를 만들 수 있고, 모든 인터페이스 메소드는 익명 메소드로 표시된다. TNoRefCountObject 새로운 클래스 System.TNoRefCountObject는 참조 카운트가 IInterface 구현이다.(오래되고 모호한 TSingletonObject를 대체) 최적화 및 기타 최적화된 _FinalizeRecord 및 _FinalizeArray 레거시 TDatamodule.OldCreateOrder 속성이 제거 되고 기본값 True로 인식. 해당 속성이 폼파일에 있는 경우 무시됨(오류 미발생). 델파이 초기 버전 생성 순서 로직과 호환성을 위해 사용 된 항목 향상된 파스칼 System.Pos TArray<T>.BinarySearch 최적화 TList<T>.Sort( ..., Index, Count ) overload 추가 System.IOUtils.TFile.Size 추가 ClassParent 및 InitInstance에 대한 TObject 성능 수정 System.IOUtils.TPath에 대한 몇 가지 개선 사항 RTL에서 260자 보다 긴 시스템 경로 지원, (최신 버전의 Windows 등)운영체제에서 지원하는 경우 클래스 속성 TThread.OnSynchronize 추가 EInOutError 및 EInOutArgumentException 메시지에 경로가 포함되고 경로 필드를 갖음 성능 향상 _UInt32ToHexString 및 _UInt64ToHexString TSingleHelper 및 TDoubleHelper용 Parse 및 TryParse TGUID 데이터 구조는 이제 System.pas에서만 정의됨 JSON ParseJSONValue()를 TJSONObject에서 TJSONValue로 이동 Integer에 대해 TJSONObject.AddPair(overload) 추가 UTF8ToString 변경 사항 array of AnsiChar을 허용하는 UTF8ToString 오버로드가 제거되고 UTF8ToString(array of Byte) 지원중단 됨. 제거된 함수: UTF8ToString(const S: _PAnsiChr) 해결 방법 은 System.UTF8ToString 참조 FireDAC PostgreSQL 드라이버는 PostgreSQL v13 지원, PostgreSQL 저장 프로시저 지원 포함 Oracle 19c 및 Oracle 저장 프로시저에 대한 128자 매개변수 이름에 대한 공식 지원 TFDSortOption에 soDigitsAsNumbers 확장, System.SysUtils의 TCompareOption과 유사 FireDAC 모니터 UI 개선 /bin 하위 폴더가 아닌 VendorHome에서 드라이버를 찾도록 Firebird 드라이버를 개선(이전 버전의 Firebird에는 정확함). Internet, HTTP 및 REST 클라이언트 라이브러리 백엔드 및 EMS 클라이언트 구성 요소에 대한 타임아웃 메커니즘: TEMSProvider, TKinveyProvider, TParseProvider 클래스는 2가지 새로운 속성: ConnectTimeout, ReadTimeout TEMSApi.TConnectionInfo, TParseApi.TConnectionInfo, TKinveyApi.TConnectionInfo: ConnectTimeout 및 ReadTimeout 변수 TDSRestConnection은 ConnectionTimeOut 표시 HTTP / 2에 대한 Windows 지원 추가 THttpClient.ProtocolVersion 신규 속성 TNetHttpClient.ProtocolVersion 신규 속성 새로운 TBase64URLEncoding 인코딩 및 TNetEncoding.Base64URL 속성 모든 플랫폼에 대해 전체 RTL에서 gethostbyname를 getaddrinfo로 전환 새로운 TCertificate.PublicKey, 공개 키 모듈 포함 ContentType은 이제 문자열 유형, 열거형이 아님 . 이로서 하나의 콘텐츠 타입 문자열 사용 가능. 또한 새로운 RestRequest의 CustomContentType Windows용 TNetHTTPClient에서 TLS 1.3 지원 TSocket에 대한 여러 개선 사항 새로운 TRESTRequestDataSetAdapter 컴포넌트는 JSON을 통해 TDataSet(예: TFDMemTable) 데이터를 서버에 업로드하는 작업 단순화. 서버 측에서 TRESTResponseDataSetAdapter REST 구성 요소의 동반자 TRestClient 구성 요소는 기본 HTTPClient 구성 요소의 SecureFailureReasons 속성을 표시함 Vcl.Styles 유닛에서 이제 TCustomStyle 클래스 FCustomElements 및 FSource가 protected 섹션에 선언됨 인터넷 서버 기술 웹브로커 ISAPI DLL 스레드에는 Web.Win.ISAPIThreadPool.StackSize 변수를 사용하여 구성 가능한 StackSize 제공. 2GB(MaxInt)보다 큰 파일을 전송/스트리밍할 때 WebBroker 성능 대폭 향상 RAD 서버 RAD 서버를 위한 Multipart/form-data 지원 데이터스냅 (DataSnap) 데이터스냅: REST URI는 이제 TDSMethodMapEvent 이벤트를 기반으로 하는 새로운 메커니즘을 사용해 구성할 수 있다. View full RAD 스튜디오 버전별 신기능
  7. RAD 스튜디오 10.3 리오 "새 기능 한글 요약본: RAD 서버" 입니다. 모든 새 기능, 강화된 기능, 버그 픽스 등에 대해서는 Docwiki의 What's New 10.3 (영문 보기, 한글번역 보기) 와 관련 페이지를 보기 바랍니다. 10.3 리오 - RAD 서버 관련 주요 업데이트 요약 [10.3.3] RAD서버 도커(Docker) 배포 기능 제공 [10.3.2] 새로운 RAD서버 관리 콘솔 재설계한 RAD서버 콘솔 UI 엔드포인트 메소드와 Content-Type, Accept 연동 특성 추가 커스텀 메소드와 HTTP 메소드 연결 특성 추가 요청 처리를 클래스 또는 컴포넌트로 위임 JSON 처리를 위한 헬퍼 컴포넌트 추가 [10.3.3] RAD서버 도커(Docker) 배포 기능 제공 기본 제공되는 스크립트로 RAD서버 도커(Docker)를 배포하고 구성할 수 있는 기능이 제공됩니다. 도커 허브(Docker Hub)에서 호스팅되는 리눅스의 RAD서버용 도커 이미지도 제공됩니다. 바로 사용할 수 있는 형태입니다! 이제 도커에서 RAD서버를 배포하는 작업이 정말 간편해집니다. 자세히 보기: https://tech.devgear.co.kr/delphi_news/457810 [10.3.2] 새로운 RAD서버 관리 콘솔 새로운 기능면에서, UI와 사용 기능상의 업그레이드 외에도 REST 디버거 통합 버전이 제공된다는 점이 가장 획기적입니다. 이제 특정 RAD 서버 인스턴스에서 사용가능한 엔드포인트를 리스트로 정리하여 볼 수 있습니다. 자세히 보기: https://tech.devgear.co.kr/delphi_news/455346 재설계한 RAD서버 콘솔 UI RAD서버 콘솔 UI가 변경되었습니다. 이제 RAD서버 API 분석을 한 눈에 확인할 수 있고, Ext JS 프레임워크로 마이그레이션 할 수도 있습니다. 또한 RAD서버 푸시 알림이 더 많은 디바이스에 지원됩니다. 추가 분석 데이터에 대한 지원도 제공됩니다. 이 기능은 IDE의 겟잇 패키지 매니저(GetIt Package Manager)를 통해 다운로드 받아 사용할 수 있습니다. 엔드포인트 메소드와 Content-Type, Accept 연동 특성 추가 커스텀 리소스에 요청 시 URL과 HTTP 메소드에만 의존하지 않고, HTTP 해더의 Accept 및 Cotnet-Type에 따라 엔드 포인트 메소드를 연결하는 특성이 추가되었습니다. 이제 동일한 URL 및 HTTP 메소드라도 Accept 및 Content-Type에 따라 다른 동작을 구현할 수 있습니다. EndpointProduce : GET 메소드의 엔드 포인트에 추가할 수 있습니다. HTTP 해더의 Accept 항목 값과 일치하는 MIME 타입/파일 확장자를 파라메터로 지정합니다. EndpointConsume : PUT / POST / PATCH 메소드의 엔드 포인트에 추가할 수 있습니다. HTTP 해더의 Content-Type 항목 값과 일치하는 MIME 타입/파일 확장자를 파라메터로 지정합니다. 커스텀 메소드와 HTTP 메소드 연결 특성 추가 RAD 서버의 이전 버전에서는 HTTP 메소드(GET, POST 등)의 엔드 포인트 메소드 이름과 매핑되었습니다. 이제 위 방식 외에도 다른이름의 메소드를 엔드 포인트 메소드로 매핑할 수 있는 EndpointMethod 특성이 추가되었습니다. 요청 처리를 클래스 또는 컴포넌트로 위임 RAD 서버의 사용자 리소스에 발생한 요청을 필드로 지정한 다른 자원 모듈(클래스 / 컴포넌트)로 위임하는 기능이 추가되었습니다. 위임받는 클래스는 IEMSEndpointPublisher 인터페이스를 구현해야 합니다. JSON 처리를 위한 헬퍼 컴포넌트 추가 컴포넌트에 요청 처리를 위임하는 새로운 기능을 이용해 RAD 스튜디오 10.3 리오에서 JSON 처리를 단순화 하는 새로운 컴포넌트가 추가되었습니다. TEMSFileResource: 경로 및 파일이름 속성에 지정된 파일로 요청 처리 TEMDDataSetResource: DataSet 속성에 설정된 데이터셋의 데이터를 JSON으로 처리, 페이징 파라메터 지원 View full RAD 스튜디오 버전별 신기능
  8. << 위로 이동 (최신 버전 포함 모든 버전) RAD 스튜디오 10.2 도쿄 "새 기능 한글 요약본: RAD 서버" 입니다. 모든 새 기능, 강화된 기능, 버그 픽스 등에 대해서는 Docwiki의 What's New 10.2 (영문 보기, 한글번역 보기) 와 관련 페이지를 보기 바랍니다. 10.2 도쿄 - RAD 서버 관련 주요 업데이트 요약 [10.2] RAD 서버 싱글 사이트 라이선스 제공 [10.2] RAD 서버 싱글 사이트 라이선스 제공 10.2.2에서 RAD 서버 싱글 사이트 라이선스를 제공합니다.(RAD 스튜디오, 델파이, C++빌더 엔터프라이즈 및 아키텍트 에디션에만 포함) RAD 서버는 즉시 사용가능한 턴키방식의 미들웨어 서버입니다. 주요 기능으로 범용적인 REST API 개발해 서비스 할 수 있으며, 엔터프라이즈 데이터베이스 제공, 통합 미들웨어 역할 수행, IoT 엣지웨어(사물인터넷 정보 수집) 등의 기능과 서비스를 모니터링 및 관리할 수 있는 웹 콘솔 서비스를 제공합니다. 자세히 보기: https://tech.devgear.co.kr/delphi_news/438369 View full RAD 스튜디오 버전별 신기능
×
×
  • Create New...

중요한 정보

이용약관 개인정보보호정책 이용규칙 이 사이트가 더 잘 작동하기 위해 방문자의 컴퓨터에 쿠키가 배치됩니다. 쿠키 설정 변경에서 원하는 설정을 할 수 있습니다. 변경하지 않으면 쿠키를 허용하는 것으로 이해합니다.