Cloud Computing On Demand

닷넷 환경에서 오라클을 개발하기 위한 방법은 크게 두가지이다. 오라클 클라이언트를 전체 설치할 때 따라오는 ODP.NET (Oracle Data Provider for .NET) 만을 이용하는 방법이 한가지이고, 다른 하나는 Visual Studio IDE 환경에 Plug-in 가능한 ODT.NET (Oracle Developer Tools for Visual Studio.NET) 을 설치해서 사용하는 방법이 다른 한가지이다.

복잡하지 않은 개발을 하는 상황이고 데이터베이스에 의존적인 개발이 적은 경우 (예>Stored Procedure 의 사용 등) 에는 전자의 방법을 사용하는 것이 간단하며, 그렇지 않은 경우는 ODT.NET 을 설치해서 사용하는 것이 디버깅, 개발 효율성 측면에서 훨씬 우수할 수 있다.

NoPD 의 경우 마이크로소프트가 닷넷 환경에서 제공하는 표준 Provider (System.Data.OracleClient) 를 사용하던 도중 오라클 Provider 로 교체를 하는 케이스를 경험했었는데, 구문이라던가 사용하는 방법이 크게 다르지 않기 때문에 마이그레이션을 하는 경우에도 전자의 방법을 강력하게 추천한다.

※ ODT.NET 다운로드 : http://tinyurl.com/lvcw56

- NoPD -

근래 몇 년간 웹서비스로 개발된 API 들은 항상 웹폼에서만 호출했었습니다. 이번에 개인적으로 사용할 서버 모니터링 프로그램을 만들면서 웹서비스를 사용하고 있었는데, 윈폼에서 호출이 1회 이상 되지 않는 문제가 발생하더군요.

처음 프로그램이 웹서비스를 호출하면 값을 잘 받아오지만, 이후부터는 값을 받아오지 못하는 문제더군요. 에러 메시지는 "기본 연결이 닫혔습니다" (영어로는 The Underlying Connection was Closed 더군요. 번역이 괜찮게 된건지 모르겠군요) 개발자의 친구, 구글신에게 물어보니 역시 좋은 해결 방안들이 있었습니다.

참고 URL : http://blog.josh420.com/archives/2008/02/underlying-connection-closed-fix-pesky-aspnet-webexception.aspx

웹서비스 Proxy 를 생성하면 reference.cs 파일이 생기는데요, 일단 이 파일을 열어서 아래의 코드를 추가해 줍니다. 환경에 따라 다른 것인지 모르겠으나, keepalive 를 true 로 해서 해결이 된다는 이야기도 있었는데 제 경우에는 해당사항이 없었습니다.


해결 방법이 조금 꽁수이긴 하나 (ConnectionGroup 이름을 계속 새로운 GUID 로 할당해주는 -_-;;) 일단 해결이 되었고 크게 누군가에게 부담을 주는 방식이 아니라 일단 사용하기로 했습니다. 유경상님의 블로그에 이 에러와 관련하여 WCF와 Fiddler의 문제를 언급한 글도 한번 읽어 보시면 유사한 상황에서 도움이 되실 것 같습니다.

 
- NoPD -

닷넷용 차트 솔루션의 대표격인 둔다스 차트(Dundas Chart) 에서 실버라이트 버전 베타 테스트를 시작했습니다. 기존 둔다스 차트 시리즈들은 JPG 등의 일반 이미지 형태의 출력과 함께 동적인 차트 구성을 위한 AJAX, Flash Exprot 등을 지원했었는데 여기에 실버라이트(SilverLight)가 새롭게 지원 가능한 항목으로 추가가 되었습니다.

둔다스 차트를 사용하면서도 참 쉽지 않았던 것이 디자이너의 감성(?)이 담긴 차트 구성을 하는 것이었는데, 실버라이트의 지원이 시작되면서 닷넷 환경에서 보다 Interactive한 차트 활용이 가능해지지 않을까 싶습니다. 일반적인 실버라이트 프로젝트를 진행하는 것처럼 디자이너와 개발자가 역할을 나누어서 작업하면 보다 아름다운 웹사이트, 어플리케이션 개발이 가능해지지 않을까 싶습니다.


둔다스 차트 실버라이트 데모는 여기를 누르시면 감상하실 수 있습니다.

- NoPD -

SAP 은 기간 시스템이기 때문에 대부분의 사업장 / 업체에서 내부 네트워크 존에 위치하게 된다. 따라서 웹 어플리케이션이나 IDC 외부의 네트워크에서 해당 서버들을 액세스 하기 위해서는 방화벽을 적절하게 개방해 줘야 하는데 아이러니하게도 많은 사업장의 SAP 개발자들은 "당연히" 그런 포트가 열려있는 상황에서 일을 하고 있기 때문에 무슨 포트가 필요한지 모르는 경우가 꽤나 많다. 간단하게 SAP 연결을 위한 포트정보 / 방화벽 설정 정보를 정리해 봤다.

기본적으로 SAP 의 모든 포트 설정은 SAP 이 설치된 서버의 /etc/services 파일의 내용을 확인하면 된다. 혹시나 사업장에 따라 이 파일을 희안하게(?) 설정하고 사용할 가능성도 있으나 대부분 표준적인 포트를 사용하고 있을 것이므로 아래의 내용을 참고하되 문제가 있는 경우 SAP 서버 관리자에게 해당 파일 내용을 확인하면 될 것 같다.


SAP 시스템은 System Number를 통해서 여러개의 시스템을 하나의 SAP 서버에 올려두는 것으로 보인다. 특히 개발장비의 경우 이런식의 구성이 꽤나 많은 편인데 Client Number, System Number로 구분을 하는 것 같은데 자세한 내용은 다음 포스팅에서 한번 연구후에 정리해 보도록 하겠다.

SAP GUI 를 이용해서 SAP 서버를 액세스 하기 위해서는 32## 포트를 개방해야 한다. 접속하려는 시스템의 System Number가 00 이라면 3200 번 포트를 개방하면 된다. RFC 를 이용해서 SAP 서버를 액세스 하기 위해서는 33## 포트를 개방하면 된다. 마찬가지로 System Number에 따라 3300 혹은 3301 따위가 포트번호가 되는 것이다.

닷넷 개발자들이 SAP .NET Connecter 를 이용해서 개발하는데는 33## 포트만 있으면 될까? 개인적으로 32## 포트도 같이 열고 SAP GUI 어플리케이션을 인스톨 하는 것을 권장한다. RFC 를 호출하다보면 제대로된 값이 나오기는 하는 것인지, 혹은 RFC 가 제대로 코딩이 된 것인지 소스코드를 확인 할 필요도 간혹 생긴다.

32## 포트를 미리 열어두면 ABAP 개발자가 만들어둔 RFC 펑션들을 소스코드까지 까보면서 오류도 찾아낼 수 있는 좋은 기회가 될 것이다. 동시에 RFC 의 허무함도 금새 알 수 있을 것이다. RFC 테스트를 위한 화면 T-Code 가 se37 이라는 것 정도도 머릿속에 넣어두도록 하자.

- NoPD -