SAP CPI 이름 규칙(Naming Convention): 팀이 지킬 수 있는 규칙 팩 만들기

대부분의 SAP Cloud Integration(SAP CPI) 팀에는 이름 규칙이 있습니다. 하지만 모든 iFlow가 그 규칙을 따르는 팀은 많지 않습니다. 규칙은 위키 페이지에 있고, 트랜스포트 전에 Content Modifier 이름을 확인하는 사람은 없기 때문입니다.

이 글에서는 단계, 채널, 속성, 주소에 쓸 출발점이 될 규칙을 제안하고, 그것을 도구가 점검할 수 있는 규칙으로 작성하는 방법과 팀이 공유하고 적용하는 방법을 보여 줍니다.

SAP CPI에서 이름이 중요한 이유

무언가 고장 났을 때 보게 되는 것이 단계의 이름입니다. 모니터는 실패한 단계를 이름으로 알려 주고, “주문 ID를 설정하는 단계”를 찾는 검색은 이름에 그렇게 쓰여 있어야만 그 단계를 찾으며, 설계 문서나 인수인계 문서는 다이어그램의 라벨을 그대로 따라 읽힙니다. “Content Modifier 3”은 아무것도 말해 주지 않지만 CM_SetOrderHeaders는 무엇을 하는지 알려 줍니다.

이름이 일관되면 두 iFlow를 비교하기도 쉬워집니다. 규칙을 아는 리뷰어는 팀의 어떤 iFlow든 한눈에 읽을 수 있습니다.

출발점이 되는 규칙

대부분의 팀에는 단계 종류를 나타내는 접두사와, 그 뒤에 PascalCase로 쓴 동작이면 충분합니다. 다음은 Kitegra에 기본으로 들어 있는 팩입니다. SAP 표준이 아니라 상황에 맞게 고쳐 쓸 출발점입니다.

이름 규칙을 점검 가능한 규칙으로 작성하기

도구가 점검할 수 있는 이름 규칙은 요소 종류마다 하나씩 있는 규칙 목록입니다. 리터럴 텍스트는 정확히 일치해야 하고, <Placeholder>는 아무 텍스트나 뜻하며, <PascalCase>, <camelCase>, <UPPER>, <lower>, <Number>는 그 형태의 텍스트를 뜻합니다. 각 종류에서는 첫 번째 규칙이 적용되며, 규칙마다 심각도가 있습니다. “오류”, “경고”, “정보” 중 하나입니다.

Kitegra에서 규칙은 JSON 규칙 팩입니다. 일부를 발췌하면 다음과 같습니다.

{
  "rules": [
    {
      "id": "content-modifier",
      "target": "content-modifier",
      "pattern": "CM_<Action>",
      "example": "CM_SetOrderHeaders",
      "notes": "Content Modifier: CM_ and what it sets.",
      "severity": "warning",
      "enabled": true
    },
    {
      "id": "mapping",
      "target": "mapping",
      "pattern": "MM_<Source>_to_<Target>",
      "example": "MM_Order_to_SalesOrder",
      "notes": "Message Mapping: source and target message.",
      "severity": "info",
      "enabled": true
    },
    {
      "id": "property",
      "target": "property",
      "pattern": "<camelCase>",
      "example": "orderId",
      "notes": "Exchange property names in camelCase.",
      "severity": "info",
      "enabled": true
    }
  ]
}

팀으로 합의하기

1. 확장 프로그램의 옵션 페이지를 열고 “이름 규칙”을 찾으세요. 기본 팩으로 시작합니다.
2. 규칙의 “패턴”, “심각도”, “메모”를 바꾸거나, “규칙 켜기”로 규칙을 끄거나, “규칙 추가”를 선택하고 “검사 대상”을 고르세요.
3. “JSON 내보내기”를 선택하고, 팀이 표준을 보관하는 곳에 트랜스포트 지침과 함께 파일을 두세요.
4. 동료는 각자 그 파일로 “JSON 가져오기”를 선택합니다. Kitegra로 로그인되어 있으면 팩이 모든 컴퓨터에서 이어집니다.

동기화는 한 사람의 팩을 그 사람의 모든 컴퓨터에서 같게 유지합니다. 팀 전체가 같은 규칙을 쓰게 하는 것은 공유한 JSON 파일입니다.

iFlow를 규칙으로 점검하기

iFlow를 열고 “Kitegra 도구” 버튼을 클릭한 뒤 “검사기”를 선택하세요(또는 Alt+Shift+K). “이름 규칙” 탭에는 규칙에 맞지 않는 모든 이름이 나열되고, 그 개수가 버튼에 표시됩니다. 실제 이름, “예상” 형태, “예시”, 그리고 단계 내용으로 알 수 있는 경우 단계의 동작을 바탕으로 만든 “제안” 이름이 나옵니다. 항목을 클릭하면 다이어그램에서 그 단계가 선택됩니다.

편집 모드에서 “이름 변경”은 제안 이름을 단계의 Name 필드에 입력합니다. 저장은 하지 않습니다. 패널에 “이름을 바꿨습니다. 유지하려면 iFlow를 저장하세요.”라고 표시되고, 결정은 사용자가 합니다.

iFlow 리뷰 체크리스트에서 보여 주듯 같은 결과가 iFlow 보고서에도 설계 점검과 함께 나타나며, 좋은 이름은 생성된 설계 문서도 읽기 좋게 만듭니다.

Kitegra가 도와주는 방법

이름 점검은 Kitegra의 iFlow Inspector에 속합니다. 점검은 브라우저에서 iFlow 모델을 읽어 실행됩니다. 로그인하면 규칙 팩이 Kitegra 계정과 동기화되며, iFlow의 내용은 전송되지 않습니다.

Helper, Message Monitor, iFlow Inspector, iFlow Docs는 각각 사용한 iFlow 수를 셉니다. Kitegra 계정이 없으면 모듈당 5개, Free 요금제는 50개, Starter는 100개, Pro는 300개이며 Business는 제한이 없습니다. Toolbox와 작업 공간 부가 기능은 무료입니다. 요금제 비교하기.

다음 iFlow에서 사용해 보세요

Kitegra가 SAP Integration Suite 디자이너에 무엇을 더하는지 읽어 보거나, Kitegra의 다른 Chrome 확장 프로그램과 함께 살펴보세요.

자주 묻는 질문