다운로드 Oracle JDeveloper & ADF

태그 java, forms, All

Oracle Forms를 Oracle ADF Faces에 통합하기

Oracle ADF 컴포넌트들을 이용하여 기존의 Forms 애플리케이션을 확장하는 방법을 배워 보십시오.

게시일: 2007년 6월

Oracle Forms가 웹을 지원하기 시작한 것도 벌써 몇 년 전의 일입니다. Oracle Forms를 웹 브라우저에서 실행하는 데에는 아무런 문제가 없습니다. 또 2005년 발표된 제품 전략 보고서(Statement of Direction)를 통해, 오라클은 앞으로도 Oracle Forms를 계속적으로 개발, 지원할 것임을 밝힌 바 있습니다.

또 한편으로, 최근 업계에는 Java/J2EE 테크놀로지의 도입이 빠른 속도로 확산되고 있으며 SOA라는 큰 흐름이 대세를 이루고 있습니다. Oracle JDeveloper와 Oracle Application Development Framework(ADF)를 이용하면 기능적으로 풍성한 JavaServer Faces(JSF) 웹 애플리케이션을 개발하는 것이 가능합니다. 본 문서에서는 이러한 두 가지 세계를 통합하는데 필요한 테크닉의 조합 방법을 설명하고 있습니다.

Oracle ADF는 Oracle JDeveloper를 통해 제공되는 혁신적인 J2EE 개발 프레임워크입니다. Oracle ADF는 잘 알려진 디자인 패턴과 애플리케이션 인프라스트럭처를 구현하기 위한 코딩 작업을 최소화함으로써 Java 개발 업무를 단순화할 수 있게 합니다. Oracle ADF는 이러한 기능들을 프레임워크의 일부로서 제공합니다.

본 문서는 ADF 프레임워크의 컴포넌트 중 하나인 ADF Faces에 초점을 맞추고 있습니다. ADF Faces는 표준 JSF API를 기반으로 하는 많은 수의 UI 컴포넌트 셋을 포함하고 있으며, 이 JSF API들을 통해 PPR(partial page rendering), Ajax 등 리치, 인터액티브 사용자 인터페이스를 제공하기 위한 최신 테크놀로지이 활용되고 있습니다. 본 문서에서는 ADF Faces를 사용하는 것을 기본 가정으로 하고 있지만 PHP, Oracle Application Express, .NET ASP와 같은 다른 웹 테크놀로지와 Oracle Forms를 통합할 때에도 동일한 테크닉을 활용하실 수 있을 것입니다.

여기에서는 Oracle Forms와 Oracle ADF Faces 통합의 극단적인 예를 제시해 보려 합니다. 이 시나리오에서는 엔드 유저가 Oracle ADF Face의 사용자 인터페이스와 기존 Oracle Forms 폼을 구현한 페이지의 차이를 전혀 눈치채지 못할 것입니다. 이러한 통합의 간단한 예가 그림 1과 같습니다. 이 화면에서는 주문(order) 정보를 보여주는 멀티레코드 블록만이 기존 Oracle Forms 폼을 사용하고 있습니다. 페이지의 나머지 부분은 Oracle ADF Faces 컴포넌트들로 구성됩니다.

그림 1 Oracle ADF Faces에 통합된 Oracle Forms 폼

이 간단한 예를 통해 몇 가지 중요한 사실을 확인할 수 있습니다.

• 시각적으로 볼 때, 폼은 Oracle ADF Faces 페이지와 긴밀하게 통합되어 있습니다. 메뉴, 툴바, 상태 표시줄 등은 보이지 않습니다. 이러한 통합 결과로 사용자의 인터페이스는 전형적인 Oracle Forms 환경에서 보다 고전적인 웹 환경으로 전환됩니다. 사용자는 Oracle ADF Faces의 이점을 점진적으로 차용하는 한편으로 Oracle Forms 애플리케이션이 기존에 제공하던 기능 역시 그대로 활용할 수 있을 것입니다. 위 화면에서, 사용자가 눈치채지 못하게 Oracle Forms 폼을 Oracle ADF Faces 테이블로 바꿔치기 하는 것은 무척 쉬운 일입니다. 하지만 경우에 따라서는 이러한 극단적인 통합 방법이 용납되기 어려울 수 있습니다. 또 사용자 인터페이스에 메뉴, 툴바 또는 상태 표시줄 등을 표시해 주어야 할 수도 있을 것입니다. 이런 경우라면 Oracle Forms의 멀티다큐먼트 인터페이스를 이용하여, 특정 작업에 한정하여 Oracle ADF Faces 페이지를 호출하는 방법을 사용하는 것이 좋을 수 있습니다.
  
  
• 위 스크린샷에서는 특정 고객의 주문만이 표시되고 있는지를 분명히 확인하기가 어렵습니다. 위 화면에서는 사용자가 선택한 고객의 정보가 (Oracle ADF Faces가 제공하는) Customers 탭에 표시되고 있습니다. 다시 말해, 선택된 고객의 ID가 Oracle Forms로 전달되어 쿼리에 사용됩니다.
  
  
• Oracle Forms는 또 전달 받은 컨텍스트 정보를 Oracle ADF Faces에 전달합니다. 사용자가 멀티 레코드 Orders 블록을 스크롤하면, Oracle ADF Faces의 detail 테이블에 대한 쿼리가 자동으로 재수행됩니다. 이는 결국 order ID가 Oracle ADF Faces로 전달되고 있으며, Oracle Forms가 Oracle ADF Faces의 (detail 테이블의 리프레시와 같은) 이벤트를 트리거할 수 있음을 의미합니다. 예에서 Oracle ADF Faces 테이블은 동일한 페이지에 위치하고 있지만, 다른 웹 페이지에도 쉽게 구현될 수도 있습니다. 여기서 중요한 것은 Oracle Forms가 컨텍스트를 Oracle ADF Faces에 전달한다는 사실입니다.
  
  
• Oracle ADF Faces 페이지에는 Save Form 입력 버튼이 위치하고 있습니다. 이 Oracle ADF Faces 버튼은 Oracle Forms에 이벤트를 전송하고 커밋을 수행할 것을 지시합니다. 이 예를 통해 Oracle ADF Faces 내에서 Oracle Forms 이벤트를 발생시키는 것이 가능함을 알 수 있습니다.
  
  
• 또 이 화면에서 Oracle Forms 애플릿의 시작 시간이 표시되지 않고 있음을 확인할 수 있습니다. Oracle Forms는 클라이언트 브라우저 환경에서 Java 애플릿을 사용합니다. 이 애플릿을 시작하려면 몇 초의 시간이 필요합니다. 사용자가 Oracle ADF Faces 페이지들을 왔다 갔다하고 그 중 일부가 Oracle Forms 폼을 포함하고 있다면, 폼이 포함된 각 페이지마다 애플릿 시작 시간을 표시하는 것이 결코 자연스러워 보이지 않을 것입니다.

애플릿의 활용

여기서 가장 먼저 넘어야 할 장애물은 Oracle ADF Faces 웹 페이지에 위치한 실제 Oracle Forms 폼입니다. 그림 2는 Oracle Forms 폼이 클라이언트 브라우저에서 실행되는 방식을 보여 주고 있습니다. 이 그림은 개념적으로 보았을 때, Oracle Forms(초록색 박스)가 클라이언트 브라우저의 웹 페이지(노란색 박스)에서 Java 애플릿(파란색 박스)으로 실행됨을 설명하고 있습니다.

그림 2 웹 페이지의 Oracle Forms 애플릿

이러한 경우 전체 웹 페이지가 Oracle Forms 서브렛에 의해 처리되는 것이 일반적입니다. 여기서, 굳이 서블렛을 이용하여 필요한 HTML 파일을 제공할 필요는 없습니다. 애플릿 시작에 필요한 HTML을 Oracle ADF FAces 웹 페이지 내에 구현하는 것이 가능하기 때문입니다.

개발자는 HTML을 렌더링하는 JSF 컴포넌트를 생성하고 이 컴포넌트를 Oracle ADF Faces 페이지에 포함시킬 수 있습니다. 본 문서의 예제에서는 하나의 영역(region)을 정의하고 정의된 영역을 전체 Oracle ADF Faces 페이지에서 재활용하는 간단한 방법을 사용하기로 합니다. 먼저 Oraclf Forms HTML을 클라이언트에 출력하기 위한 Oracle ADF Faces 태그를 정의하는 JSPX 파일을 생성합니다:

	  
<?xml version='1.0' encoding='windows-1252'?>
<af:regionDef var="regionParams" 
              xmlns:f="http://java.sun.com/jsf/core"
              xmlns:af="http://xmlns.oracle.com/adf/faces">
  <f:verbatim>
    . . . { actual HTML and JavaScript goes here } . . .
  </f:verbatim>
</af:regionDef>	  

Next, register this region in the META-INF/region-metadata.xml file:

	  
<component>
  <component-type>com.example.oracleFormRegion</component-type>
  <component-class>oracle.adf.view.faces.component.UIXRegion</component-class>
  <component-extension>
    <region-jsp-ui-def>/regions/oraFormsRegion.jspx</region-jsp-ui-def>
  </component-extension>
  <attribute>
    <attribute-name>formModuleName</attribute-name>
    <attribute-class>java.lang.String</attribute-class>
  </attribute>
</component>	  

Finally, you can reuse this definition with <af:region> on every Oracle ADF Faces page that needs to embed an Oracle Forms form:

  
<af:region id="oraFormRegion" regionType="com.example.oracleFormRegion">
  <f:attribute name="formModuleName" value="orders.fmx" />
</af:region>	  

<af:regionDef>, <af:region> 태그를 이용하여 Oracle Forms를 단 한 차례 실행하는데 필요한 HTML과 JavaScript를 정의하고, 정의된 영역을 Oracle Forms 폼이 임베드되는 모든 Oracle ADF Faces 페이지에서 재활용할 수 있습니다.

인바운드 JavaScript API

이 시나리오에서는 Oracle Forms와 Oracle ADF Faces를 연계하기 위한 테크닉이 매우 중요합니다. 두 환경이 서로 간에 커뮤니케이션할 수 있도록 구현되어야 합니다. 이러한 기능이 구현되어야만, 다른 환경에 컨텍스트(예: 현재 선택된 레코드의 ID)를 전달하거나 다른 환경에서 이벤트를 발생시킬 수 있을 것입니다. 이를 위해 JavaScript 기반 API가 사용됩니다. Oracle ADF Faces는 Oracle Forms의 호출을 위해 JavaScript를 사용할 수 있습니다. Oracle Forms 역시 Oracle ADF Faces와의 커뮤니케이션을 위해서는 JavaScript를 실행해야 합니다.

첫번째 테크닉으로, 먼저 Oracle ADF FAces가 Oracle Forms에서 이벤트를 발생시키고, 이를 통해 Oracle Forms에서 PL/SQL 코드를 실행하도록 하는 인바운드 JavaScript API를 사용해 보겠습니다. 인바운드 JavaScript가 활용되는 간단한 예로 Oracle ADF Faces의 "Save" 버튼이 Oracle Forms 폼을 커밋하는 동시에 같은 페이지에 있는 Oracle ADF Faces의 입력 데이터를 제출, 저장하는 경우를 들 수 있습니다.

Oracle Forms 10g Release 2와 그 이전 버전에서는 네이티브 JavaScript API가 지원되지 않고 있습니다. 이 기능은 Oracle Forms 11g에서 새로이 구현될 예정입니다. 하지만 주요 웹 브라우저를 모두 지원하는 업계 표준, LiveConnect API를 이용하여 Oracle Forms 10g Release 2(또는 이전 버전)에서 이 기능을 구현하는 것이 가능합니다. 이 API를 이용하면 JavaScript가 Java 클래스의 퍼블릭 메소드를 호출할 수 있도록 지원할 수 있습니다. Oracle Forms 애플릿은 Java 클래스로 구현되며, 이 클래스가 퍼블릭 메소드를 공개하고 있다면 JavaScript를 통해 호출하는 것이 가능할 것입니다.

오라클이 기본 제공하는 Oracle Forms 애플릿은 퍼블릭 메소드를 제공하지 않지만, 여러분이 직접 추가할 수는 있습니다. Oracle Forms 애플릿 클래스 oracle.forms.engine.Main을 서브-클래스 처리하고 퍼블릭 메소드 raiseEvent()를 추가합니다. 새로 추가된 퍼블릭 메소드는 클라이언트-사이드 JavaScript에서 호출 가능하며, 페이로드(메시지)를 수신한 후 Oracle Forms로 전달합니다.(그림 3의 Step 1):

	 
document.formsapplet.raiseEvent('do_key', 'commit_form');	 

그림 3 인바운드 JavaScript API

퍼블릭 raiseEvent() 메소드는 활성화된 Oracle Forms 폼의 코드를 트리거하는데 사용되어야 합니다. 이 작업은 직접 구현은 불가능합니다. 다행스럽게도 Oracle Forms는 이러한 요구 사항을 해결하기 위해 Pluggable Java Components(PJC)라는 이름의 프레임워크를 제공하고 있습니다. PJC는 oracle.forms.ui.VBean을 서브-클래스 처리한 JavaBean입니다. oracle.forms.ui.VBean은 Oracle Forms 폼 안에 인클루드 처리가 가능합니다. 이제 제너릭한 PJC를 생성하여 인바운드 JavaScript 커뮤니케이션을 처리할 수 있을 것입니다. 이 PJC를 각각의 폼에 임베드하는 것을 잊지 마시기 바랍니다. 확장된 Oracle Forms 애플릿의 퍼블릭 메소드는 액티브 폼 내에서 PJC의 핸들을 가져오고 PJC에 페이로드를 전달할 수 있습니다(그림 3의 Step 2):

	  
public void raiseEvent(String event, String payload) {
  CommunicatorBean communicator = findFirstCommunicator();
  if (null != communicator) {
    communicator.sendMessageToForms(event, payload);
  }
}	 

PJC는 WHEN-CUSTOM-ITEM-EVENT라는 이름의 Oracle Forms 트리거를 호출할 수 있습니다(그림 3의 Step 3):

public void sendMessageToForms(String event, String payload) {
  try {
    // set properties to pass to Oracle Forms
    mHandler.setProperty(PROP_EVENT, event);
    mHandler.setProperty(PROP_PAYLOAD, payload);
    // trigger WHEN-CUSTOM-ITEM-EVENT trigger in Forms
    CustomEvent ce = new CustomEvent(mHandler, EVENT_MSG_TO_FORMS);
    dispatchCustomEvent(ce);
  } catch (FException e) {
    e.printStackTrace();
  }
}

마지막으로, PL/SQL 코드를 사용하여 이벤트의 페이로드를 검사하고 그 결과에 따라 처리할 수 있습니다:

		
declare
  BeanEventDetails  ParamList;
  ParamType         number := text_parameter;
  Event             varchar2(1000);
  Payload           varchar2(1000);
begin
  BeanEventDetails := get_parameter_list(:system.custom_item_event_parameters);
  get_parameter_attr(BeanEventDetails, 'Event',   ParamType, Event);
  get_parameter_attr(BeanEventDetails, 'Payload', ParamType, Payload);
  if event='do_key' then
    do_key(payload);
  end if;
end;		

이것으로 클라이언트-사이드 JavaScript에서 Oracme Forms-사이드 PL/SQL 코드에 이르는 호출 경로를 완성했습니다. 먼저 클라이언트-사이드 JavaScript가 확장된 Oracle Forms 애플릿의 퍼블릭 메소드를 호출하고 페이로드를 전달하는 것부터 시작됩니다(Step 1). 다음으로 퍼블릭 메소드는 액티브 Oracle Forms 폼의 PJC에 대한 핸들을 가져오고, 이 PJC의 퍼블릭 메소드를 호출하여 페이로드를 전달합니다(Step 2). PJC는 이어 WHEN-CUSTOM-ITEM-EVENT 트리거를 트리거하고, 다시 페이로드를 전달합니다(Step 3). 마지막으로 트리거를 처리하는 PL/SQL 코드가 페이로드를 검사하고 그 결과에 따라 처리합니다.

아웃바운드 JavaScript API

다음으로 Orcle Forms가 호스팅된 웹 페이지 상에서 이벤트를 트리거할 수 있어야 합니다. 이 기능은 Oracle Forms와 웹 애플리케이션이 컨텍스트, 이벤트를 주고 받을 때 사용됩니다. 전형적인 예로 Oracle Forms의 멀티레코드 블록을 스크롤하면서 선택된 레코드의 ID를 웹 애플리케이션에 전달하는 경우를 들 수 있습니다.

이러한 커뮤니케이션은 아웃바운드 JavaScript API를 통해 구현할 수 있습니다. 아웃바운드 JavaScript API란 Oracme Forms가 PL/SQL로부터 JavaScript를 실행할 수 있게 하는 API를 의미합니다.

아웃바운드 JavaScript API는 인바운드 JavaScript API에서 사용한 것과 동일한 PJC와 연동이 가능합니다. PL/SQ의 SET_CUSTOM_PROPERTY를 이용해서 매개변수를 PJC에 전달할 수 있습니다(그림 4의 Step 1):

        
begin
  -- set the Order ID
  set_custom_property('BLK_PJC.PJC', 1, 'EvalExpression',
    'document.getElementById(''frm:ordid'').value=' || :ord.ordid);
end;		 

그림 4 아웃바운드 JavaScript API

이 경우, PJC의 속성은 실행될 JavaScript로 설정됩니다. 이제 PJC는 포함된 Java 애플릿에 대한 핸들을 가져올 수 있습니다(그림 4의 Step 2). 이 애플릿은 LiveConnect API의 일부로서 JavaScript를 실행하기 위한 메소드를 제공합니다(그림 4의 Step 3):

	  
public boolean setProperty(ID property, Object value) {
  if (PROP_EVAL_EXPR == property) {
    JSObject appletWindow = JSObject.getWindow(mHandler.getApplet());
    Object evalResult = appletWindow.eval(value.toString());
    // make result available as PJC property
    setProperty(PROP_EVAL_RESULT, evalResult);
    return true;
  }
}	 

위 에제 코드는 웹 페이지의 입력 엘리먼트에 값을 설정하는 작업만을 수행합니다. 동일한 아웃바운드 JavaScript API를 이용하여 웹 페이지를 다시 웹 서버에 전달할 수 있습니다. 이는 사용자가 검색 폼에서 Order ID를 입력하고 Submit 버튼을 누르는 것과 동일한 효과를 갖습니다.

애플릿의 사용 중단/재활용

Oracle Forms는 웹 브라우저에서 실행되는 Java 애플릿을 이용하여 폼을 디스플레이하고 사용자 인터액션을 처리합니다. Oracle Form 폼처럼 용량이 큰 Java 애플릿을 실행하려면 많은 리소스가 필요하며 완료되기 까지 수 초가 걸릴 수도 있습니다. 일반적인 Oracle Forms 설치 환경이라면 이것은 문제가 되지 않습니다. 세션을 시작하면서 Oracle Forms 애플릿을 실행하고 다른 웹 페이지로 이동하지 않은 상태에서 일정 기간 작업을 수행하는 것이 보통이기 때문입니다. 하지만 이 아티클에서 예로 든 시나리오에서는 사용자가 서로 다른 웹 페이지를 왔다 갔다 하고 있습니다. 또 이 페이지들 중 일부는 Oracle Forms를 포함하고 있으며 또 나머지는 그렇지 않습니다. 웹 브라우저와 Sun Microsystem의 Java Virtual Machine은 디폴트 설정 상태에서 사용자가 페이지를 벗어나면 애플릿을 삭제 처리합니다.

Java Virtual Machine 버전 1.4.2 또는 그 이상의 버전을 클라이언트에서 사용 중이라면, 애플릿의 HTML에서 legacy_lifecycle이라는 매개변수를 추가로 설정할 수 있습니다. 이 매개변수는 사용자가 페이지로부터 벗어나더라도 애플릿을 삭제하지 않도록 JVM을 설정합니다. 그 대신, 애플릿은 백그라운드에서 실행을 계속하면서 레거시 라이프사이클 캐시(legacy lifecycle cache)라 불리는 곳에서 대기합니다. 이 애플릿은 사용자가 (완전하게 동일한 애플릿 선언을 포함하는) 웹 페이지로 다시 돌아온 경우 재활성화됩니다. 이는 기존의 애플릿이 다시 활성화되려면 애플릿의 HTML이 라이프사이클 캐시에 저장된 내용과 100 퍼센트 똑같아야 함을 의미합니다. HTML을 JSF 리전 또는 JSF 커스텀 컴포넌트에서 단 한 번만 선언하는 것이 좋은 또 다른 이유를 바로 여기서 찾을 수 있습니다.

이 기능을 사용하게 되면 애플릿은 전체 브라우저 세션에 대해 단 한 차례만 실행될 것입니다. 따라서 사용자가 Oracle Forms 폼을 포함하는 페이지로 다시 돌아왔을 때, 애플릿의 시작 시간은 전혀 필요하지 않습니다.

애플릿 재활성화에 대해

애플릿은 캐시로부터 복귀할 때 실행이 중단된 시점의 바로 그 상태에서 실행을 재개합니다. 따라서 이전의 웹 페이지에서 실행되던 Oracle Forms 폼이 여전히 실행되고 있을 것입니다. 이런 이유 때문에라도 애플릿을 재활성화할 때 몇 가지 조치가 필요할 수 있습니다. 안타깝게도, Oracle Forms 트리거는 애플릿 재활성화 과정에서는 지원되지 않습니다. 대신, 애플릿이 재활성화될 때 Oracle Forms의 (악명 높은) show() 메소드가 호출됩니다. 이 메소드가 실행되지 않게 하는 방법이 아래와 같습니다:

            
public void show() {
  super.show();
  raiseEvent("WHEN-APPLET-ACTIVATED", "");
}			

이 코드는 인바운드 JavaScript API를 사용하여 Oracle Forms에 이벤트를 전달하고 PJC의 WHEN-CUSTOM-ITEM-EVENT 트리거를 통해 처리될 수 있게 합니다:

				
declare
  BeanEventDetails  ParamList;
  ParamType         number := text_parameter;
  Event             varchar2(1000);
  Payload           varchar2(1000);
begin
  BeanEventDetails := get_parameter_list(:system.custom_item_event_parameters);
  get_parameter_attr(BeanEventDetails, 'Event',   ParamType, Event);
  get_parameter_attr(BeanEventDetails, 'Payload', ParamType, Payload);
  if event='WHEN-APPLET-ACTIVATED' then
    -- add handling here
  end if;
end;

랜딩 폼(landing form)의 필요성

애플리케이션에 사용되는 모든 Oracle ADF Faces 페이지들이 모두 Oracle Forms 폼을 포함하고 있는 경우가 있습니다. 각각의 페이지는 서로 다른 폼을 호출하고 있을 것입니다. 이 폼들의 이름을 애플릿의 HTML에서 일반적인 매개변수 형태로 전달할 수는 없습니다. 그렇게 하려면 각 웹 페이지의 HTML이 모두 달라져야 하며, 결국 레거시 라이프사이클 기능의 기본 목적이 무색하게 됩니다. 레거시 라이프사이클 기능은 실행 중단된 애플릿의 재활용을 위해 100 퍼센트 동일한 HTML 코드를 요구하고 있기 때문입니다.

이런 경우라면, Oracle Forms 폼의 이름으로 동일한 "랜딩 폼(landing form)"을 명시하는 방법으로 요구 사항을 해결할 수 있습니다. 시작되는 실제 폼의 이름은 웹 페이지에 히든 엘리먼트(hidden element)로 포함될 수 있습니다.

	  
<input type="hidden" id="formname" value="orders.fmx"/>  

랜딩 폼에서 WHEN-NEW-FORM-INSTANCE 트리거는, 아웃바운드 JavaScript API를 이용하여 document.getElementById('formname').value의 값을 얻고 이 결과를 통해 필요한 폼이 무엇인지 결정하는데 사용됩니다. 그런 다음, 랜딩 폼은 요청된 폼을 실행합니다:

	  
declare
  formName varchar2(1000);
begin
  while true loop
    -- get the form name
    set_custom_property('BLK_PJC.PJC', 1, 'EvalExpression', 
      'document.getElementById(''frm:oraFormRegion:formname'').value');
    formName := get_custom_property('BLK_PJC.PJC', 1, 'EvalResult');
    -- start the form
    call_form(formName);
    if (get_custom_property('BLK_PJC.PJC', 1, 'AppletActive')='FALSE' then
      -- exit the loop if the user is closing the browser
      exit;
    end if;
  end loop;
end;	  

라이프사이클 캐시에서 애플릿이 재활성화되면 "실제" 폼이 실행됩니다. 이 폼은 자신의 실행을 종료함으로써 애플릿 재활성화를 처리합니다. 그 결과로 랜딩 폼의 무한 루프에 컨트롤이 반환되고, 랜딩 폼은 호스팅된 웹 페이지를 다시 검사하여 어떤 폼이 시작되어야 하는지 확인합니다. 이 무한 루프는 사용자가 브라우저를 닫고 애플릿이 삭제될 때 종료됩니다.

Oracle Forms에 컨텍스트 가져 오기

웹 애플리케이션에서 Oracle Forms로 컨텍스트를 전달할 때 레거시 라이프사이클 기능이 문제가 될 수 있습니다. Oracle Forms 폼을 이용하여 Oracle ADF Faces 페이지 내의 주문을 편집하고자 하는 경우를 생각해 봅시다. 이를 위해서는 Oracle ADF Faces 애플리케이션에서 Oracle Forms에 선택된 order ID를 전달하는 과정이 필요할 것입니다. 여기에서도. Oracle Forms 애플릿이 포함되도록 HTML에 매개변수를 추가하는 일반적인 방법으로는 해결할 수 없습니다. 앞의 경우와 마찬가지로 각 주문별로 다른 HTML이 필요해지며, 따라서 애플릿 재활용이 의미가 없어지기 때문입니다.

이번에도, 아웃바운드 JavaScript API를 이용해서 이 문제를 해결할 수 있습니다. order ID(또는 전달하고자 하는 컨텍스트)를 Oracle ADF Faces 페이지에 히든 아이템으로 포함시키는 방법이 그것입니다. Oracle Forms는 WHEN-NEW-FORM-INSTANCE 트리거 과정에서 이 값을 확인하고 그 결과에 따라 처리를 수행합니다.

	  
declare
  orderID  number;
begin
  -- get the order ID
  set_custom_property('BLK_PJC.PJC', 1, 'EvalExpression', 
    'document.getElementById(''frm:orderID'').value');
  customerID := get_custom_property('BLK_PJC.PJC', 1, 'EvalResult');
  :parameter.ordid:=orderID;
  -- execute query (where clause refers :parameter.ordid)
  do_key('execute_query');
end;

시각적 통합

Oracle ADF Faces 페이지에 단 하나의 폼을 포함시킨 후 사용자가 다른 Oracle Forms 폼으로 이동할 수 없도록 강제할 수 있습니다. 여기서 한 걸음 더 나아가, 사용자가 자신이 사용하는 인터페이스가 Oracle Forms가 아닌 것처럼 믿게 만드는 것도 가능합니다. 이를 위해서는 Oracle Forms가 기본적으로 제공하는 메뉴, 툴바, 상태 표시줄, 경계선 등을 제거해야 합니다.

이를 위한 가장 쉬운 방법은 Oracle Forms 애플릿을 '클리핑(clipping)' 처리하는 것입니다. 애플릿 HTML를 (사각형 영역을 표현하기 위한) <div> 엘리먼트로 감싸 줍니다. <div>의 높이와 길이는 Oracle Forms 애플릿의 사이즈보다 작게 설정될 수 있습니다. 또, Oracle Forms 애플릿의 x, y 포지션은 주변을 둘러싼 <div> 엘리먼트에 대해 음수 값으로 설정될 수 있으며, 이렇게 하는 경우 Oracle Forms 폼의 상대적 영역만을 표시하는 작은 윈도우가 표시됩니다. 그 결과로 표시되는 영역을 그림 5에서 확인할 수 있습니다:

그림 5 뷰 포트의 제한을 통해 클리핑 처리된 Oracle Forms 폼

결론

지금까지 설명드린 것처럼, ADF Faces를 이용하여 기존 Oracle Forms 애플리케이션을 확장하는 것이 가능합니다. 이러한 방법으로 ADF Faces의 최신 기능을 활용하는 동시에 기존의 Forms 구축 환경에 대한 투자를 보호할 수 있습니다.

또 Oracle Forms 사용자 환경에서 보다 고전적인 웹 사용자 환경으로 전환하기 위한 테크닉을 활용하실 수 있습니다. 이때 Oracle Forms 폼이 표시하는 메뉴, 툴바, 상태 표시줄은 모두 제거해 주는 것이 좋습니다. 기존의 Oracle Forms 폼은 Oracle ADF Faces 웹 페이지에서 사용하는 오브젝트 중 하나로 활용됩니다. 애플리케이션의 모든 플로우 컨트롤이 Oracle ADF Faces에 의해 처리되므로, 사용자에게 직관적인 웹 환경을 제공하고 또 한 편으로 기존 폼을 활용하도록 할 수 있습니다. 이러한 접근 방법을 사용해서 애플리케이션의 프론드엔드에 Oracle ADF Faces를 점진적으로 구현해 나가는 것이 가능합니다.

또 통합 과정에서 Oracle Forms 폼을 임베드한 포틀렛을 구현할 수도 있습니다. 이 포틀렛은 Oracle Portal 환경 또는 얼마 전 출시된 Oracle WebCenter 테크놀로지 환경에서 활용이 가능합니다.

테크놀로지의 또 다른 활용 예로 웹 페이지에 개별 Oracle Forms 폼을 임베드하여 BPEL 휴먼 태스크를 완성할 수 있습니다. Oracle BPEL은 비즈니스 프로세스를 모니터, 컨트롤하는 역할을 담당합니다. 비즈니스 프로세스는 관리자 승인, 구매 주문 거부 등의 휴먼 태스크를 어느 시점엔가 필요로 할 수 있습니다. 본 문서에서 설명된 기술을 활용하면 기존 Oracle Forms 폼을 재활용하여 BPEL 휴먼 태스크의 구매 주문을 편집하는데 사용할 수 있습니다.

지금가지 설명한 테크닉들은 애플리케이션 환경에 전혀 새로운 가능성을 열기 위한 기반으로 활용이 가능합니다. 조금만 깊이 고민해 본다면, 여러분 나름대로 기업 내에서 이 기술들을 활용하기 위한 방안을 고안해 내실 수 있을 것입니다. www.oratransplant.nl/oracle-forms-as-web-component 페이지에 방문하셔서 보다 자세한 정보를 얻으시기 바랍니다. 샘플 통합 환경을 구현하기 위한 단계별 가이드와 전문 자료, 샘플 애플리케이션 등이 제공되고 있습니다.

Wilfred van der Deijl는 Eurotransplant의 선임 시스템 아키텍트입니다. 그는 12 년 넘는 오라클 툴 사용 경험을 가지고 있습니다. 그는 오라클을 주제로 한 웹블로그, OraTransplant를 운영하고 있으며, "개발 툴을 위한 오라클 고객 자문 위원회"의 회원입니다.