KR20130119715A

KR20130119715A - 비즈니스 프로세스 자동화 장치

Info

Publication number: KR20130119715A
Application number: KR1020120042730A
Authority: KR
Inventors: 최정란; 오병택; 허성진
Original assignee: 한국전자통신연구원
Priority date: 2012-04-24
Filing date: 2012-04-24
Publication date: 2013-11-01

Abstract

본 발명은 SaaS 어플리케이션 개발 때에 이용되는 비즈니스 프로세스 자동화 장치에 관한 것이다. 본 발명은 SaaS 어플리케이션으로부터 테넌트 맞춤형으로 비즈니스 프로세스를 생성하는 프로세스 생성부; 생성된 비즈니스 프로세스를 검증하는 프로세스 검증부; 검증된 비즈니스 프로세스를 유저 인터페이스에 의한 비즈니스 로직에 매핑시키는 프로세스 매핑부; 및 매핑된 비즈니스 프로세스에 대한 프로세스 인스턴스가 발생되면 매핑된 비즈니스 프로세스의 자동화를 실행하는 프로세스 자동화부를 포함하는 것을 특징으로 하는 비즈니스 프로세스 자동화 장치를 제안한다. 본 발명에 따르면 신뢰할 수 있는 어플리케이션의 개발이 가능해지며 SaaS 어플리케이션을 테넌트에게 안정적으로 서비스할 수 있다.

Description

비즈니스 프로세스 자동화 장치{Business process automation apparatus}

본 발명은 비즈니스 프로세스 자동화 장치에 관한 것이다. 보다 상세하게는, SaaS(Software as a Service) 어플리케이션 개발 때에 이용되는 비즈니스 프로세스 자동화 장치에 관한 것이다.

SaaS(Software as a Service)는 어플리케이션 SW 배포 모델로서 인터넷을 통해 사용자에게 온라인 서비스 형태로 SW를 제공한다. 전통적인 SW 비즈니스 모델 방식과 달리 SaaS 서비스는 사용량에 따라 비용을 지불하고, SW 공급과 유지 보수, 업그레이드 등이 모두 웹을 통해 이루어지므로 관련 SW나 HW 구매 비용, 운용비, 인건비 등 관련 비용이 기존 대비 획기적으로 절약된다.

SaaS는 하나의 어플리케이션 개발을 통하여 다양한 고객(테넌트)에게 맞춤형 서비스를 제공할 수 있도록 멀티테넌시 기능을 제공한다. 개발된 어플리케이션의 코드 수정 또는 코드 수정에 따른 재컴파일이나 재수정 없이 실시간으로 어플리케이션을 수정할 수 있는 기능을 제공한다. 이러한 기능을 통하여 고객들은 자신들에게 맞는 비즈니스적인 요구사항을 어플리케이션에 반영할 수 있기 때문에 단기간에 최적의 서비스를 제공받을 수 있게 된다.

워크플로우는 SaaS 어플리케이션 개발에서 비즈니스 프로세스의 자동화를 지원하기 위해 사용된다. 특히 멀티테넌시를 지원하는 SaaS 어플리케이션을 개발하기 위해 기존 어플리케이션의 워크플로우와는 다른 기능들이 제공될 필요가 있다. 정의된 워크플로우는 내부적으로 BPEL/WSDL 같은 표준 XML 언어로 저장되어 처리될 수 있다.

이와 같이 종래에는 비즈니스 프로세스를 처리하기 위해 BPEL, WSDL 등의 여러 언어 및 방법론이 제안되거나 활용되고 있다. 특히 여러 서비스들의 결합을 통해 이루어지는 비즈니스 업무는 오케스트레이션, 코레오그래피 등의 방법을 통해 이루어진다. 그러나, 이 방법들은 데드락(deadlock), 라이브락(livelock), 리퀘스트-리스펀스(request-response) 등의 발생으로 인해 SaaS 어플리케이션을 테넌트에게 불안정하게 서비스하는 문제점이 있다.

본 발명은 상기한 문제점을 해결하기 위해 안출된 것으로서, 비즈니스 프로세스를 검증하고 검증된 비즈니스 프로세스를 대상으로 비즈니스 프로세스를 자동화하는 비즈니스 프로세스 자동화 장치를 제안함을 목적으로 한다.

본 발명은 상기한 목적을 달성하기 위해 안출된 것으로서, SaaS(Software as a Service) 어플리케이션으로부터 테넌트(tenant) 맞춤형으로 비즈니스 프로세스(business process)를 생성하는 프로세스 생성부; 생성된 비즈니스 프로세스를 검증하는 프로세스 검증부; 검증된 비즈니스 프로세스를 유저 인터페이스(user interface)에 의한 비즈니스 로직(business logic)에 매핑시키는 프로세스 매핑부; 및 매핑된 비즈니스 프로세스에 대한 프로세스 인스턴스(process instance)가 발생되면 상기 매핑된 비즈니스 프로세스의 자동화를 실행하는 프로세스 자동화부를 포함하는 것을 특징으로 하는 비즈니스 프로세스 자동화 장치를 제안한다.

바람직하게는, 상기 프로세스 검증부는, 상기 생성된 비즈니스 프로세스를 정형 기법(formal method)에 이용될 정형 언어로 변환하는 프로세스 변환부; 및 변환된 정형 언어를 기초로 속성 만족 여부에 따라 상기 생성된 비즈니스 프로세스를 검증하는 조건 부합성 판단부를 포함한다.

바람직하게는, 상기 조건 부합성 판단부는 상기 속성으로 시제 논리 모델 체킹(temporal logic model checking)을 통한 이벤트 발생, 사용자의 비즈니스 프로세스 이용을 방해하는 이벤트 미발생, 상기 비즈니스 프로세스 이용과 관련된 요청에 대한 자동 응답, 비즈니스 프로세스의 정상 실행, 사용자 의도에 부합하는 비즈니스 프로세스의 실행, 및 버전이 다른 비즈니스 프로세스와의 동일성 중 적어도 하나를 이용한다.

바람직하게는, 상기 프로세스 변환부는 상기 정형 언어로 프로세스 알제브라(process algebra)를 이용한다.

바람직하게는, 상기 프로세스 검증부는 상기 비즈니스 프로세스가 안전하게 실행되는지 여부를 검증한다.

바람직하게는, 상기 프로세스 생성부는, 워크플로우(workflow) 및 상기 워크플로우를 구성하는 액티비티(activity)를 기초로 상기 SaaS 어플리케이션으로부터 공용 비즈니스 프로세스를 정의하는 프로세스 제너레이터; 및 정의된 공용 비즈니스 프로세스의 내용을 테넌트의 요구에 적합하게 수정하여 테넌트 맞춤형 비즈니스 프로세스를 생성하는 프로세스 디자이너를 포함한다.

바람직하게는, 상기 프로세스 검증부는 서로 다른 속성을 이용하여 상기 공용 비즈니스 프로세스와 상기 테넌트 맞춤형 비즈니스 프로세스를 구분하여 검증한다.

또한, 본 발명은 SaaS(Software as a Service) 어플리케이션으로부터 테넌트(tenant) 맞춤형으로 비즈니스 프로세스(business process)를 생성하는 프로세스 생성 단계; 생성된 비즈니스 프로세스를 검증하는 프로세스 검증 단계; 검증된 비즈니스 프로세스를 유저 인터페이스(user interface)에 의한 비즈니스 로직(business logic)에 매핑시키는 프로세스 매핑 단계; 및 매핑된 비즈니스 프로세스에 대한 프로세스 인스턴스(process instance)가 발생되면 상기 매핑된 비즈니스 프로세스의 자동화를 실행하는 프로세스 자동화 단계를 포함하는 것을 특징으로 하는 비즈니스 프로세스 자동화 방법을 제안한다.

바람직하게는, 상기 프로세스 검증 단계는, 상기 생성된 비즈니스 프로세스를 정형 기법(formal method)에 이용될 정형 언어로 변환하는 프로세스 변환 단계; 및 변환된 정형 언어를 기초로 속성 만족 여부에 따라 상기 생성된 비즈니스 프로세스를 검증하는 조건 부합성 판단 단계를 포함한다.

바람직하게는, 상기 조건 부합성 판단 단계는 상기 속성으로 시제 논리 모델 체킹(temporal logic model checking)을 통한 이벤트 발생, 사용자의 비즈니스 프로세스 이용을 방해하는 이벤트 미발생, 상기 비즈니스 프로세스 이용과 관련된 요청에 대한 자동 응답, 비즈니스 프로세스의 정상 실행, 사용자 의도에 부합하는 비즈니스 프로세스의 실행, 및 버전이 다른 비즈니스 프로세스와의 동일성 중 적어도 하나를 이용한다.

바람직하게는, 상기 프로세스 변환 단계는 상기 정형 언어로 프로세스 알제브라(process algebra)를 이용한다.

바람직하게는, 상기 프로세스 검증 단계는 상기 비즈니스 프로세스가 안전하게 실행되는지 여부를 검증한다.

바람직하게는, 상기 프로세스 생성 단계는, 워크플로우(workflow) 및 상기 워크플로우를 구성하는 액티비티(activity)를 기초로 상기 SaaS 어플리케이션으로부터 공용 비즈니스 프로세스를 정의하는 프로세스 제너레이팅 단계; 및 정의된 공용 비즈니스 프로세스의 내용을 테넌트의 요구에 적합하게 수정하여 테넌트 맞춤형 비즈니스 프로세스를 생성하는 프로세스 디자이닝 단계를 포함한다.

바람직하게는, 상기 프로세스 검증 단계는 서로 다른 속성을 이용하여 상기 공용 비즈니스 프로세스와 상기 테넌트 맞춤형 비즈니스 프로세스를 구분하여 검증한다.

본 발명은 비즈니스 프로세스를 검증하고 검증된 비즈니스 프로세스를 대상으로 비즈니스 프로세스를 자동화함으로써 다음 효과를 얻을 수 있다. 첫째, SaaS 어플리케이션을 개발할 때에 비즈니스 프로세스를 검증함으로써 SaaS 어플리케이션을 테넌트에게 안정적으로 서비스할 수 있다. 둘째, SaaS 어플리케이션에서 발생하는 프로세스들 간 실행의 safety, liveness 등을 보장받거나, 비즈니스 프로세스의 여러 버전들 간 일관성이나 어플리케이션 개발자가 개발한 비즈니스 프로세스와 테넌트 관리자가 수정한 비즈니스 프로세스 간 일관성을 보장받음으로써 신뢰할 수 있는 어플리케이션의 개발이 가능해진다.

도 1은 본 발명의 바람직한 실시예에 따른 비즈니스 프로세스 자동화 장치를 개략적으로 도시한 블록도이다.
도 2는 도 1에 도시된 비즈니스 프로세스 자동화 장치의 내부 구성을 세부적으로 도시한 블록도이다.
도 3은 프로세스 알제브라를 이용한 문제 영역 검증 방법의 개략도이다.
도 4는 SaaS 플랫폼 구조를 도시한 개념도이다.
도 5는 프로세서 정의 과정을 보여주는 참고도이다.
도 6은 프로세서 디자이너에서 UI와 비즈니스 로직 간 매핑 과정을 보여주는 참고도이다.
도 7은 비즈니스 프로세스 자동화 과정을 개략적으로 설명한 흐름도이다.
도 8은 CCS와 WSDL/BPEL 간 구조적 매핑 관계를 보여주는 테이블도이다.
도 9는 Sanitary agency 프로세스를 BPEL과 CCS로 표현한 예시도이다.
도 10은 검증 기능이 추가된 비즈니스 프로세스 자동화 방법을 개략적으로 도시한 흐름도이다.
도 11은 본 발명의 바람직한 실시예에 따른 비즈니스 프로세스 자동화 방법을 개략적으로 도시한 흐름도이다.

이하, 본 발명의 바람직한 실시예를 첨부된 도면들을 참조하여 상세히 설명한다. 우선 각 도면의 구성요소들에 참조 부호를 부가함에 있어서, 동일한 구성요소들에 대해서는 비록 다른 도면상에 표시되더라도 가능한한 동일한 부호를 가지도록 하고 있음에 유의해야 한다. 또한, 본 발명을 설명함에 있어, 관련된 공지 구성 또는 기능에 대한 구체적인 설명이 본 발명의 요지를 흐릴 수 있다고 판단되는 경우에는 그 상세한 설명은 생략한다. 또한, 이하에서 본 발명의 바람직한 실시예를 설명할 것이나, 본 발명의 기술적 사상은 이에 한정하거나 제한되지 않고 당업자에 의해 변형되어 다양하게 실시될 수 있음은 물론이다.

도 1은 본 발명의 바람직한 실시예에 따른 비즈니스 프로세스 자동화 장치를 개략적으로 도시한 블록도이다. 도 2는 도 1에 도시된 비즈니스 프로세스 자동화 장치의 내부 구성을 세부적으로 도시한 블록도이다. 이하 설명은 도 1과 도 2를 참조한다.

도 1에 따르면, 비즈니스 프로세스 자동화 장치(100)는 프로세스 생성부(110), 프로세스 검증부(120), 프로세스 매핑부(130), 프로세스 자동화부(140), 전원부(150) 및 주제어부(160)를 포함한다.

프로세스 생성부(110)는 SaaS(Software as a Service) 어플리케이션으로부터 테넌트(tenant) 맞춤형으로 비즈니스 프로세스(business process)를 생성하는 기능을 수행한다.

프로세스 생성부(110)는 도 2 (b)에 도시된 바와 같이 프로세스 제너레이터(111) 및 프로세스 디자이너(112)를 포함할 수 있다.

프로세스 제너레이터(111)는 워크플로우(workflow) 및 워크플로우를 구성하는 액티비티(activity)를 기초로 SaaS 어플리케이션으로부터 공용 비즈니스 프로세스를 정의하는 기능을 수행한다.

프로세스 디자이너(112)는 정의된 공용 비즈니스 프로세스의 내용을 테넌트의 요구에 적합하게 수정하여 테넌트 맞춤형 비즈니스 프로세스를 생성하는 기능을 수행한다. 상기에서, 공용 비즈니스 프로세스는 SW 개발자 또는 APP 개발자에 의해 정의된 비즈니스 프로세스를 의미하며, 테넌트 맞춤형 비즈니스 프로세스는 테넌트 관리자에 의해 수정된 비즈니스 프로세스를 의미한다.

프로세스 검증부(120)는 생성된 비즈니스 프로세스가 안전하게 실행되는지 여부를 검증하는 기능을 수행한다. 프로세스 검증부(120)는 공용 비즈니스 프로세스와 테넌트 맞춤형 비즈니스 프로세스를 구분하여 검증할 때 서로 다른 속성을 이용하여 상기 두 프로세스를 구분하여 검증할 수 있다.

프로세스 검증부(120)는 도 2 (a)에 도시된 바와 같이 프로세스 변환부(121) 및 조건 부합성 판단부(122)를 포함할 수 있다.

프로세스 변환부(121)는 생성된 비즈니스 프로세스를 정형 기법(formal method)에 이용될 정형 언어로 변환하는 기능을 수행한다. 프로세스 변환부(121)는 정형 언어로 프로세스 알제브라(process algebra)를 이용할 수 있다.

조건 부합성 판단부(122)는 변환된 정형 언어를 기초로 속성 만족 여부에 따라 비즈니스 프로세스를 검증하는 기능을 수행한다. 조건 부합성 판단부(122)는 비즈니스 프로세스 검증을 위한 속성으로 시제 논리 모델 체킹(temporal logic model checking)을 통한 이벤트 발생, 사용자의 비즈니스 프로세스 이용을 방해하는 이벤트 미발생, 비즈니스 프로세스 이용과 관련된 요청에 대한 자동 응답, 비즈니스 프로세스의 정상 실행, 사용자 의도에 부합하는 비즈니스 프로세스의 실행, 및 버전이 다른 비즈니스 프로세스와의 동일성 중 적어도 하나를 이용할 수 있다. 상기에서, 시제 논리 모델 체킹을 통한 이벤트 발생을 보장하는 속성은 라이브니스(liveness)로 정의된다. 사용자의 비즈니스 프로세스 이용을 방해하는 이벤트 미발생을 보장하는 속성은 세이프티(safety)로 정의된다. 사용자의 비즈니스 프로세스 이용과 관련된 요청에 대한 자동 응답을 보장하는 속성은 리퀘스트-리스펀스(request-response)로 정의된다. 비즈니스 프로세스의 정상 실행 여부는 시뮬레이션 기법을 통해 확인할 수 있으며, 사용자 의도에 부합하는 비즈니스 프로세스의 실행 여부는 실행중인 비즈니스 프로세스를 추적하여 확인할 수 있다. 버전이 다른 비즈니스 프로세스와의 동일성 여부는 계층적 정제(hierarchical refinement) 기법 예컨대, 시뮬레이션(simulation) 기법과 바이시뮬레이션(bisimulation) 기법을 통한 일관성 여부로 확인할 수 있다.

프로세스 매핑부(130)는 검증된 비즈니스 프로세스를 유저 인터페이스(user interface)에 의한 비즈니스 로직(business logic)에 매핑시키는 기능을 수행한다.

프로세스 자동화부(140)는 매핑된 비즈니스 프로세스에 대한 프로세스 인스턴스(process instance)가 발생되면 매핑된 비즈니스 프로세스의 자동화를 실행하는 기능을 수행한다.

전원부(150)는 비즈니스 프로세스 자동화 장치(100)를 구성하는 각 구성부에 전원을 공급하는 기능을 수행한다.

주제어부(160)는 비즈니스 프로세스 자동화 장치(100)를 구성하는 각 구성부의 전체 작동을 제어하는 기능을 수행한다.

본 발명은 SaaS 어플리케이션을 개발할 때 비즈니스 프로세스를 자동화하기 위해 워크플로우를 적용하는 과정에서 검증 과정을 추가하여 신뢰할 수 있는 어플리케이션을 개발하는 방법에 관한 것이다.

종래 비즈니스 프로세스를 처리하기 위해 제안된 방법들은 deadlock, livelock, request-response 등으로 인해 SaaS 어플리케이션을 테넌트에게 불안정하게 서비스하는 문제점이 있다. 본 발명은 이러한 문제점을 요구사항 정의나 설계 단계에서 정형적으로(formally) 해결하기 위해 정형기법 언어들을 활용한다. 정형기법 언어들 중 특히 프로세스 알제브라는 웹 서비스 사이에서 메시지 교환을 명세하기에 용이한 언어이다. 본 발명에서는 도 3에 도시된 바와 같이 PA(Process Algebra) 도구(320)를 이용하여 특정 문제 영역(예컨대, 웹 서비스 제공 영역(310))을 PA 명세언어(330)로 명세/설계한 후 BPEL, WSDL 등의 언어(340)로 자동으로 변환할 수 있는 방법들을 이용한다. 도 3은 프로세스 알제브라를 이용한 문제 영역 검증 방법의 개략도이다. 이러한 것이 가능한 이유는 프로세스 알제브라, 예를 들어, CCS, CSP, LOTOS, SPIN 등에서 표현하는 방식들이 WS의 BPEL의 표현 방식을 모두 포함하고 있기 때문이다. 이러한 특성으로 인해 설계 단계에서 프로세스 알제브라로 명세된 웹 서비스는 자동으로 WS를 정의하는 BPEL 또는 WSDL로 변환되고, 또는 이들 언어로 구현된 것들이 역으로 프로세스 알제브라로 쉽게 변경될 수 있다. 이러한 특징은 WS가 정형적으로 검증이 가능함을 의미하여 웹 상에서 개발되는 서비스들이 설계 단계 또는 구현 단계에서 검증되어 안정된 서비스를 제공할 수 있음을 의미한다. 즉, BPEL 또는 WSDL로 디자인하여 프로세스 알제브라로 검증할 수 있다. 특히 프로세스 알제브라의 명세 언어로 검증할 수 있다는 것은 자동화 도구를 활용하여 temporal property, 행위적 동일성, execution trace 등을 검증할 수 있다는 것과 같다. 이처럼 기존의 웹 서비스에서 비즈니스 프로세스 검증을 위해 사용되던 방법을 SaaS 어플리케이션을 개발할 때 비즈니스 프로세스를 자동화하기 위해 워크플로우를 정의한 후 검증 단계에서 역공학 모델의 형태로 적용할 경우 복잡한 비즈니스 프로세스의 안정성이 검증되므로, 결제 등의 업무의 중요도를 요구하는 프로세스 개발시 적용한다면 보다 안정적인 서비스를 제공할 수 있을 것이다.

앞서 설명한 바와 같이, 본 발명은 SaaS 어플리케이션 개발에서 비즈니스 프로세스 자동화를 위한 워크플로우 정의시 검증 과정을 추가함으로써 안전한 비즈니스 프로세스를 제공하는 데에 그 목적이 있다.

도 4는 SaaS 플랫폼 구조를 도시한 개념도이다. 도 4를 참조하면, SaaS 플랫폼(410)은 설정환경(420), 실행엔진(430) 및 메타데이터 관리자(440)로 구성된다. SW 개발자(450)는 설정환경(420)의 통합도구(421)를 통해 SaaS 어플리케이션을 개발한다. 통합도구(421)를 통해 만들어진 SaaS 어플리케이션은 테넌트 관리자(460)가 자사에 맞는 어플리케이션을 설정하기 위하여 설정도구(422)를 통하여 어플리케이션을 수정할 수 있다.

설정환경(420)의 통합/설정 도구(421, 422)를 통해 생성된 SW의 설정 정보(사용자 인터페이스, 스키마, 워크플로우(또는 비즈니스 로직) 등)는 메타데이터 생성기(423)에 의해 메타데이터로 변환되고 메타데이터 관리자(440)를 통해 데이터베이스(470)에 저장된다. 메타데이터 관리자(440)는 테넌트별 메타데이터 및 어플리케이션 데이터를 관리하는 시스템으로 데이터의 독립성을 지원하고 데이터 스키마 확장 기능을 지원한다.

테넌트 사용자(480) 즉, 테넌트 관리자(460)로부터 설정된 어플리케이션을 사용하는 사용자로부터 서비스 요청을 받을 경우, 실행엔진(430)은 해당 테넌트의 메타데이터를 검색하여 메타데이터 기반으로 서비스를 생성한 후 테넌트 사용자(480)에게 제공한다.

비즈니스 프로세스 자동화를 위한 워크플로우는 일련의 액티비티의 연결이며, 각 액티비티는 이를 수행할 참여자, 액티비티가 실행할 행위(프로그램 로직 실행, 어플리케이션 호출, 웹 서비스 실행, 시스템 서비스 연동 등) 등으로 정의된다. 워크플로우는 구성된 액티비티를 실행할 여러 참여자들이 순차적인 작업을 처리하거나 참여자가 지정되지 않은 일회적인 조건 검증 등과 같이 트리거를 처리하는 프로시저 등이 될 수 있다.

SaaS 어플리케이션 개발 과정에서 비즈니스 프로세스 자동화를 처리하기 위한 과정은 다음과 같이 진행된다.

SW 개발자는 통합도구를 통해 어플리케이션에서 사용 가능한 프로세스를 정의한다. 프로세스 정의는 도 5의 도면부호 510과 같이 플로우차트 형태로 프로세스 흐름, 액티비티 정보, 역할 및 필요한 변수, 버전 정보 등을 정의할 수 있다. 도 5는 프로세서 정의 과정을 보여주는 참고도이다.

통합/설정 도구에서 어플리케이션이 사용할 비즈니스 프로세스에 대한 정의는 프로세스 디자이너를 통해서 작성 및 수정할 수 있다. 통합도구를 통해 어플리케이션 레벨에서 공용으로 사용할 프로세스 정의를 작성/수정하고, 설정도구를 통해 특정 테넌트에 맞게 정의된 프로세스들을 수정 또는 삭제가 가능하다. 프로세스 디자이너를 통해 정의된 워크플로우들은 여러 버전들로 저장할 수 있는 버전 컨트롤을 지원한다.

프로세스 디자이너를 통해 정의된 프로세스의 액티비티와 실제 시스템의 업무를 매핑할 수 있다. 도 6은 프로세서 디자이너에서 UI와 비즈니스 로직 간 매핑 과정을 보여주는 참고도이다. SaaS 어플리케이션을 개발할 때 통합도구의 UI configurator로 작성한 UI(User Interface) Meta(610)와 프로세스 액티비티를 연결한다. 즉 프로세스 액티비티가 실행될 때 사용되는 UI는 UI Meta(610)가 된다. UI Meta(610)는 통합도구를 통해 개발된 SaaS 어플리케이션용 사용자 인터페이스로서, 테넌트 개발자는 설정도구를 통해 UI Meta(610) 정보를 자사의 특성에 맞게 수정/삭제 등이 가능하다. UI Meta(610) 내부에서 실행될 비즈니스 로직(Business Logic, BL; 620)에 대한 정의 및 설정은 Java나 Java Script 등의 코드를 작성하거나 미리 정의된 코드를 통하여 DB와의 연동 등을 수행할 수 있다.

SaaS 어플리케이션은 기본적으로 UI Meta를 사용하지만, 워크플로우 설정에서는 비즈니스 프로세스 정의시 필요한 UI를 간단히 생성 및 수정할 수 있는 기능 제공을 통하여 사용자 인터페이스의 유연성을 제공한다. 간단한 UI는 통합/설정 도구에서 폼 디자이너를 통해 생성/수정 가능하며 작성된 폼은 액티비티와 매핑되어 프로세스 실행시 UI로 사용된다.

프로세스 디자이너를 통해 정의된 워크플로우 리스트들은 설정도구에서 테넌트 관리자 또는 이벤트 트리거에 의해서 프로세스가 시작하게 된다. 이때 프로세스 인스턴스가 발행된다. 설정도구에서 인스턴스 관리는 테넌트와 관련한 프로세스 인스턴스 리스트를 보여주고, 테넌트 관리자는 해당 인스턴스를 중지/재시작/삭제할 수 있다. 또한 테넌트 사용자가 참여하고 있는 화면에서 자신이 참여하고 있는 업무 리스트를 출력하여 보여준다.

위의 기능 이외에도 SaaS 어플리케이션 개발에서 워크플로우 기능을 추가하기 위해 정의된 비즈니스 프로세스 리스트에 대한 접근 권한을 설정하는 기능, 즉 ACL(Access Control List)를 지원하여야 한다. 통합도구에서 SW 개발자는 사용자/부서/역할 등의 레벨에 따라 프로세스 정의 리스트에 대한 접근 권한을 설정할 수 있다. 설정환경에서는 테넌트 사용자가 프로세스 정의 리스트의 인스턴스 발행을 요청할 시 접근 권한을 조사한 후 권한이 있다면 인스턴스를 발행하도록 허락한다.

테넌트 사용자는 자신이 수행할 업무(WIH, Work Item Handler)를 처리화면에서 볼 수 있다. 이러한 WIH에는 해당 프로세스 액티비티에 매핑된 UI meta, 폼, URL 등의 정보가 있으며 이를 통해 해당 업무를 승인(confirm), 저장(save), 완료(complete)할 수 있다.

위의 과정을 통해 정의된 비즈니스 프로세스는 어플리케이션 실행시 자동화되어 처리된다. 이러한 경우 프로세스가 자동화를 거치면서 프로세스 간의 메시지 교환 등 프로세스 행위에서 발생될 수 있는 상황에 대한 safety, liveness 등을 보장할 수 없다. 또한 테넌트 관리자가 일부 프로세스 동작에 대한 수정을 했을 시 발생할 수 있는 문제 및 이전 프로세스와 동일한 동작이 가능한지를 확인할 수 있는 방법이 없다.

특히, 업무의 중요도가 높고 정확도가 요구되는 프로세스의 경우 위와 같이 문제가 발생한다면 프로세스가 멈추거나 원하지 않는 동작들이 발생할 수 있는 가능성이 있다. 이러한 문제를 해결하기 위해 본 발명에서는 비즈니스 프로세스의 정의 및 수정이 발생한 후 검증 과정을 추가함으로써 프로세스의 안전성을 보장하여 SaaS 어플리케이션 전체의 안전성 및 올바른 동작을 수행할 수 있도록 보장할 수 있다.

위에서 설명한 것과 같이 SaaS 플랫폼에서 어플리케이션 개발시 비즈니스 프로세스를 자동화하기 위한 방법은 도 7과 같이 정리될 수 있다. 도 7은 비즈니스 프로세스 자동화 과정을 개략적으로 설명한 흐름도이다. 이하 설명은 도 7을 참조한다.

어플리케이션(App) 개발자(710)는 필요한 UI 및 필요한 BL을 정의하고(731) 비즈니스 프로세스를 플로우차트 형태로 프로세스 흐름, 액티비티 정보, 필요한 변수, 역할 설정 등을 정의한다(732). 정의된 플로우의 각 액티비티에 필요에 따라 미리 정의된 UI와 비즈니스 로직 등을 매핑한다(733). 이렇게 매핑된 비즈니스 프로세스들은 인스턴스로 발생되어 실행된다(734). 필요에 따라 테넌트 관리자(720)는 UI 및 비즈니스 프로세스의 정의를 수정할 수 있고(741), 일부 BL을 수정 반영할 수 있다(742).

비즈니스 프로세스 정의 후 이 프로세스들이 잘 정의되어 실행될 수 있는지에 대한 검증 과정을 추가할 수 있다. 이러한 검증 과정을 통해 정의된 프로세스는 실제 실행시 그 안전성이 보장되어 보다 안전한 SaaS 어플리케이션을 실행할 수 있다.

비즈니스 프로세스 정의는 내부적으로 BPEL이나 WSDL등 XML 형태의 구조 언어로 정의된다. 이 언어들은 정형적 검증 언어의 형태인 프로세스 알제브라의 구조와 일대일 매핑 형태를 이룰 수 있는 구조를 가지고 있다. BPEL/WSDL과 CCS 사이의 매핑은 예컨대 도 8에 도시된 바와 같이 개념적으로 연결될 수 있다. 도 8은 CCS와 WSDL/BPEL 간 구조적 매핑 관계를 보여주는 테이블도이다.

도 9는 Sanitary agency 프로세스를 BPEL과 CCS로 표현한 예시도이다. 노인들(Citizen)이 건강 이상이 발생했을 때 Sanitary agnecy에게 요청을 하면 다른 요청이 없을 때는 에이전트 서비스를 제공해주는 프로세스이다. 이때 은행에 관련 요금을 지불했는지에 관한 프로세스들이 결합되어 병렬적으로 수행되는 웹서비스의 사례라 볼 수 있다.

CCS의 프로세스 알제브라로 정의된 서비스들은 CWB-NC 도구를 사용하여 문법적 오류나 타입 체킹 뿐만 아니라, 데드락, 서비스들 간의 인터액션시 발생할 수 있는 데드락 가능성, 기존 버전과의 일관적인 행위적 동일성의 검증 등을 체크할 수 있다. 이렇게 검증 과정을 통해 safety 또는 liveness가 확인된 CCS 버전의 프로세스는 자동적으로 WSDL/BPEL로 변환되어 웹서비스에 적용되어 구현할 수 있다.

위와 같은 과정을 SaaS 어플리케이션 개발시 비즈니스 프로세스 자동화 정의를 위한 검증 과정에 추가함으로써 보다 안정적인 SaaS 어플리케이션을 개발할 수 있다. 도 10은 검증 기능이 추가된 비즈니스 프로세스 자동화 방법을 개략적으로 도시한 흐름도이다. 이하 설명은 도 10을 참조한다.

SaaS 어플리케이션을 개발하는 개발자와 개발된 어플리케이션을 자사에 맞게 커스터마이징하는 테넌트 관리자는 비즈니스 프로세스 개발시 검증 과정을 추가하여 개발을 진행할 수 있다. 이 검증 과정은 어플리케이션 개발자와 테넌트 관리자가 서로 다른 속성들을 적용할 수 있다.

도 8과 같이 프로세스 알제브라의 언어들은 BPEL/WSDL과 구조적으로 유사한 형태를 보이고 있다. 도 10에서 비즈니스 프로세스 정의(1031) 후 BPEL/WSDL로 저장된 프로세스들은 정형기법 언어들로 자동/반자동으로 변환되어(1032) 각자 변환된 언어가 제공하는 도구들을 사용하여 검증을 수행한다(1033).

검증(1033)은 각각 어플리케이션 개발자(1010)나 테넌트 관리자(1020)가 검증하고자 하는 특성(속성)에 따라서 다양하게 적용할 수 있다. Temporal logic model checking을 통해 앞으로 어떤 이벤트가 일어날 수 있음을 보장하는 liveness, 서비스를 멈추게 하는 것과 같이 좋지 않은 이벤트가 발생하지 않음을 보장하는 safety, 서비스에서 메시지 요청이 발생하면 반드시 응답이 있음을 보장하는 request-response 등의 속성에 따라 검증할 수 있다.

Simulation 기법을 적용하여 서비스가 제대로 자동 composition되는지 확인할 수 있고, 서비스의 실행 추적(execution trace of service)을 통해 원하는 방향대로 동작하는지 검증할 수 있다.

Hierachical refinement 기법을 통해 여러 버전의 비즈니스 프로세스 정의들의 동일성 검증(1033a)을 수행할 수 있다. 즉, Simuation과 Bisimuation 분석을 통해 현재 버전과 이전 버전의 일관성 체크가 가능하다. 또한 어플리케이션 개발자(1010)가 개발해 놓은 비즈니스 프로세스를 테넌트 관리자(1020)가 일부 수정한 후 이전에 정의해 놓은 것과 일관성을 검증하는 데도 활용될 수 있다. 예를 들어, 대출이나 결제와 같은 프로세스들은 회사 내부 사정에 따라 세세한 절차는 다르지만, 결제나 대출에 필요한 큰 흐름은 동일하기 때문에 내부적 관점(internal behavior)이 아닌 외부적 관점(external behavior)에 따라 일관성 및 동일성을 검증할 수 있다.

검증 속성을 만족한다면(1034) UI/BL과 검증된 비즈니스 프로세스를 매핑한다(1035). 이때 업무 UI/BL 생성 과정(1041)을 통해 생성된 UI/BL이 이용된다. 이렇게 매핑된 비즈니스 프로세스들은 인스턴스로 발생되어 실행된다(1036).

테넌트 관리자(1020)에 의해 수정된 비즈니스 프로세스는 어플리케이션 개발자(1010)에 의해 정의된 비즈니스 프로세스와 같은 방식으로 자동화될 수 있다. 다만, UI/BL과 검증된 비즈니스 프로세스 간 매핑(1051)에 이용되는 것은 업무 UI/BL 수정 과정(1052)을 통해 수정된 UI/BL임에 유의한다.

이와 같이 프로세스 알제브라를 통한 비즈니스 프로세스의 검증은 보다 안전한 비즈니스 서비스를 제공함을 보장한다.

다음으로, 도 1 및 도 2에 도시된 비즈니스 프로세스 자동화 장치의 비즈니스 프로세스 자동화 방법에 대해서 설명한다. 도 11은 본 발명의 바람직한 실시예에 따른 비즈니스 프로세스 자동화 방법을 개략적으로 도시한 흐름도이다. 이하 설명은 도 1, 도 2 및 도 11을 참조한다.

먼저, 프로세스 생성부(110)가 SaaS(Software as a Service) 어플리케이션으로부터 테넌트(tenant) 맞춤형으로 비즈니스 프로세스(business process)를 생성한다(프로세스 생성 단계; S10).

프로세스 생성 단계(S10)는 다음과 같이 세분화되어 수행될 수 있다. 먼저, 프로세스 제너레이터(111)가 워크플로우(workflow) 및 워크플로우를 구성하는 액티비티(activity)를 기초로 SaaS 어플리케이션으로부터 공용 비즈니스 프로세스를 정의한다(프로세스 제너레이팅 단계). 이후, 프로세스 디자이너(112)가 정의된 공용 비즈니스 프로세스의 내용을 테넌트의 요구에 적합하게 수정하여 테넌트 맞춤형 비즈니스 프로세스를 생성한다.

프로세스 생성 단계(S10) 이후, 프로세스 검증부(120)가 생성된 비즈니스 프로세스를 검증한다(프로세스 검증 단계; S20). 프로세스 검증부(120)는 비즈니스 프로세스가 안전하게 실행되는지 여부를 검증한다. 프로세스 검증부(120)는 서로 다른 속성을 이용하여 공용 비즈니스 프로세스와 테넌트 맞춤형 비즈니스 프로세스를 구분하여 검증할 수 있다.

프로세스 검증 단계(S20)는 다음과 같이 세분화되어 수행될 수 있다. 먼저, 프로세스 변환부(121)가 생성된 비즈니스 프로세스를 정형 기법(formal method)에 이용될 정형 언어로 변환한다(프로세스 변환 단계; S21). 프로세스 변환부(121)는 정형 언어로 프로세스 알제브라(process algebra)를 이용할 수 있다. 프로세스 변환 단계(S21) 이후, 조건 부합성 판단부(122)가 변환된 정형 언어를 기초로 속성 만족 여부에 따라 비즈니스 프로세스를 검증한다(조건 부합성 판단 단계; S22). 조건 부합성 판단부(122)는 속성으로 시제 논리 모델 체킹(temporal logic model checking)을 통한 이벤트 발생, 사용자의 비즈니스 프로세스 이용을 방해하는 이벤트 미발생, 비즈니스 프로세스 이용과 관련된 요청에 대한 자동 응답, 비즈니스 프로세스의 정상 실행, 사용자 의도에 부합하는 비즈니스 프로세스의 실행, 및 버전이 다른 비즈니스 프로세스와의 동일성 중 적어도 하나를 이용할 수 있다.

프로세스 검증 단계(S20) 이후, 프로세스 매핑부(130)가 검증된 비즈니스 프로세스를 유저 인터페이스(user interface)에 의한 비즈니스 로직(business logic)에 매핑시킨다(프로세스 매핑 단계; S30).

이후, 매핑된 비즈니스 프로세스에 대한 프로세스 인스턴스(process instance)가 발생되면 프로세스 자동화부(140)가 매핑된 비즈니스 프로세스의 자동화를 실행한다(프로세스 자동화 단계; S40).

이상의 설명은 본 발명의 기술 사상을 예시적으로 설명한 것에 불과한 것으로서, 본 발명이 속하는 기술 분야에서 통상의 지식을 가진 자라면 본 발명의 본질적인 특성에서 벗어나지 않는 범위 내에서 다양한 수정, 변경 및 치환이 가능할 것이다. 따라서, 본 발명에 개시된 실시예 및 첨부된 도면들은 본 발명의 기술 사상을 한정하기 위한 것이 아니라 설명하기 위한 것이고, 이러한 실시예 및 첨부된 도면에 의하여 본 발명의 기술 사상의 범위가 한정되는 것은 아니다. 본 발명의 보호 범위는 아래의 청구 범위에 의하여 해석되어야 하며, 그와 동등한 범위 내에 있는 모든 기술 사상은 본 발명의 권리 범위에 포함되는 것으로 해석되어야 할 것이다.

100 : 비즈니스 프로세스 자동화 장치 110 : 프로세스 생성부
111 : 프로세스 제너레이터 112 : 프로세스 디자이너
120 : 프로세스 검증부 121 : 프로세스 변환부
122 : 조건 부합성 판단부 130 : 프로세스 매핑부
140 : 프로세스 자동화부 150 : 전원부
160 : 주제어부

Claims

SaaS(Software as a Service) 어플리케이션으로부터 테넌트(tenant) 맞춤형으로 비즈니스 프로세스(business process)를 생성하는 프로세스 생성부;
생성된 비즈니스 프로세스를 검증하는 프로세스 검증부;
검증된 비즈니스 프로세스를 유저 인터페이스(user interface)에 의한 비즈니스 로직(business logic)에 매핑시키는 프로세스 매핑부; 및
매핑된 비즈니스 프로세스에 대한 프로세스 인스턴스(process instance)가 발생되면 상기 매핑된 비즈니스 프로세스의 자동화를 실행하는 프로세스 자동화부
를 포함하는 것을 특징으로 하는 비즈니스 프로세스 자동화 장치.