Yong Study

패스트캠퍼스의 올인원패키지 : 프론트엔드의 진유림 강사님의 GIT특강을 보고 정리 한 내용입니다.

서로 카톡이나 메일로 소스 공유하고 수정할 부분 찾아서 수정하고 합치고 다시 저장해서 서로 공유하고...

→ 너무 복잡하고 힘들다... 어디 고쳐야 할지도 헷갈리고...

→ 서로의 수정버젼이 다를 수 있고...

→ 마치 대학교 조별과제_완성.ppt, 조별과제_진짜완성.ppt... 같이 파일만 무수히 많아져서 공유하기도 힘들거고...

이러한 버전들을 관리하고 ( 완성본까지의 수정본까지 ) 원하는 버전을 가져오고 수정할수도 있고 합쳐서 관리에 매우 용이해진다

CLI와 GUI 두가지로 GIT 사용 가능

• 각각 장단점...이 있다
• 둘 다 할 줄 알아야 상황에 따라 대처하기 좋다.

절차

1. 프로젝트 폴더 설정
   • git init
2. 코딩
3. 원하는 파일 선택
   • git add
4. 선택한 파일들 병합
   • git commit -m "~"
5. 프로젝트 저장소 만들고
6. 프로젝트 폴더에 저장소 주소 주고
   • git remote add
7. 내 컴퓨터에 프로젝트 폴더에 만든 덩어리 GitHub에 업로드
   • git push

git init

• git init하면 기본으로 숨김 처리 된 폴더가 생기고 이 폴더를 로컬저장소라고 하는데 여기에서 버전 관리를 하게 됨, 직접적으로 건들일은 없고 명령어로 제어!
• 단 하나의 폴더에는 하나의 로컬저장소만 유지!

cmd로 원하는 디렉토리 가서 git init 명령어 입력

오류 발생한다면... 환경변수 다시 잡아주거나 git 설치경로 다시 한번 확인하기

README.md 파일 하나 만들고

git add [README.md](http://readme.md/)

git commit -m "README.md 추가"

확인해보려면

git log

다 추가하려면

git add .
git commit -m "다 추가"

이러면 버전 생성됨.

• 의미있는 변동사항을 묶어서 커밋을 만들자
• 버튼 하나를 수정하는데 다수의 파일을 수정했다면 다수의 파일을 묶어서 커밋!
• 커밋 메시지는 꼭 작성하자.

여기까진 내 로컬 저장소에 버전관리 되고 있음

이걸 원격저장소 (Github)등에 올려서 온라인 및 타인과 버전 관리

git remot add origin https://github.com/아이디/이름.git

git puch origin master

기본 브랜치가 master이기에

나는 main!

git hub 로그인 해서 new repository하고

이렇게 만들어주기

만들고나서 cmd로 돌아가서

remote add와

push 해주자!

진짜 너무나도 단순한 실수...

한참을 해매었다.

SE93에서 유지보수뷰 T-CODE를 생성하는데

트랜잭션값을 SE30을 주고

밑에 Default Value에 화면필드 이름인 VIEWNAME과 UPDATE를 주려고 했다.

당연히 입력은 되지 않고 유지보수뷰 설정값을 잘못 줬다고 생각하고 한참을 헤메다

결국 잘못된 점은 트랜잭션 SE30이 아닌 SM30을 넣어줘야 했다는 것

정말 바보같은 실수였다.

NativeSQL ( 책에서는 Oracle DB )

• ABAP 프로그램에서는 NativeSQL은 OpenSQL에 비해 자주 사용되지는 않지만

• OpenSQL에서 지원하지 않는 다양하고 복잡한 SQL을 사용할 수 있다.

• 장점

  • ABAP Dictionary에 생성되지 않은 테이블에 접근할 수 있다.
  • 데이터베이스 의존 SQL구문이므로 OPEN SQL에서는 구현할 수 없는 SQL 가능!

• 단점

  • EXEC ~ ENDEXEC 사이의 구문 점검이 수행되지 않아 DUMP Error가 발생 가능

  • NATIVE SQL이 포함된 ABAP프로그램은 다른 DB를 사용하는 환경에는 적용할 수 없다.

  • Client를 구분하는 MANDT 필드를 SQL 구문 내에 반드시 포함해야 함

    ※MANDT

기본구문

EXEC SQL.
    <NATIVE SQL statement>
ENDEXEC.

• EXEC SQL로 시작해서 ENDEXEC. 로 종료
• 변수명 앞에는 : 콜론 사용

PERFORMING 구문

• 한 번에 여러 개의 데이터를 IT에 삽입

EXEC SQL PERFORMING <form>.
    <NATIVE SQL statement.
ENDEXEC.

JOIN 구문

EXEC SQL.
    ...
    FROM TABLE1 A, TABLE2 B
    WHERE A.MANDT = B.MANDT
        AND A.CARRID = B.CARRID
        AND A.MANDT = :SY-MANDT
        AND A.CARRID = :GV_CARRID
    ...
ENDEXEC.

• OUTER JOIN을 사용하려면

EXEC SQL.
    ...
    FROM TABLE1 A, TABLE2 B
    WHERE A.MANDT(+) = B.MANDT
        AND A.CARRID(+) = B.CARRID
        AND A.MANDT = :SY-MANDT
        AND A.CARRID = :GV_CARRID
    ...
ENDEXEC.

SUBSTRING 구문

LV_CHAR = ABCDE "일때 BC를 추출하려면

* 아밥에서는
LV_CHAR+2(2)

* 오라클 NATIVE SQL에서는
SUBSTR( LV_CHAR, 2, 2)

Fetch Size

• *보다는 개별 필드를 SELECT 하는것이 효과적
• Fetch Size는 Oracle DB에서 사용하는 기술로 테이블에서 데이터를 가져와 Buffer Cache에 저장하고 나서 Fetch Size만큼 논리적인 단위로 읽기를 수행하는 방법

데이터 변경

1. INSERT 구문

   • 테이블에 하나 또는 여러개의 데이터 삽입

     1) Single Line

   • 테이블 하나에 Line을 삽입하기 위한 문장

     INSERT INTO <target> VALUES <wa>.
     INSERT <target> FROM <wa>.

     2) Several Line

   • 인터널 테이블의 모든 값을 한 번에 테이블에 삽입

   • 같은 KEY값을 INSERT하게 되면 error가 발생하는데 이를 방지하기 위해 ACCEPTING DUPLICATE KEYS 구문을 사용한다.

     • 중복된 키가 입력된 값을 INSERT 하게 되면 신규행은 정상 입력 중복된 값을 미입력, INSERT 구문이 실패하면 SY-SUBRC 값 4를 반환

     INSERT <target> FROM TABLE <itab>
                                           [ACCEPTING DUPLICATE KEYS].

2. UPDATE 구문

   • 테이블 하나 또는 여러 line을 변경함

     UPDATE INTO <target> <lines>.

     1) Single Line

     2) Several Lines

   • Work Area를 사용하는 것보다 UPDATE SET 구문을 이용해 개별 컬럼 값을 변경하는 것이 성능이 우수

     UPDATE <target> SET <set 1> <set 2> WHERE <cond>

3. DELETE 구문

   • 테이블 하나 또는 여러 line의 데이터를 삭제

     1) Single Line

     2) Several Lines

4. MODIFY 구문

   • UPDATE + INSERT 의 기능을 수행

   • 키 값을 가지는 데이터가 테이블에 존재하면 UPDATE

   • 존재하지 않으면 INSERT

     1) Single Line

     2) Several Lines

테이블의 데이터를 확인하는 방법

1. SE11 : 테이블과 같은 오브젝트를 조회/수정/생성하는 용도
   • 데이터 조회버튼을 클릭하면 SE16이 호출됨
2. SE16 : 데이터를 조회하는 용도

둘 중 익숙한 트랜잭션을 사용하면 됨.

효율적인 SQL문 구문 작성

1. 적중 리스트 최소화
   • 결과 리스트가 최소화 되도록 WHERE 절을 구성
2. 전송되는 데이터양의 최소화
   • 결과로 나오는 데이터양을 최소화 하여 전송 ( UP TO ~ROWS 와 같이 )
3. LOOP에 소요되는 비용 최소화
   • Nested SELECT 구문 피하기
4. 검색 비용의 최소화
   • index를 활용하고
   • OR 구문 피하기
   • AND와 EQ 구문으로 쿼리 구성
5. 데이터베이스의 부담 제거
   • ORDER BY 보다는 SORT 사용
6. 인덱스에 사용된 필드 모두 기술
   • 인덱스에 사용된 모든 필드는 될 수 있으면 모두 기술하기
   • RANGE 변수를 적극 활용하기
7. 가급적 Application Server에서 실행
   • ORDER BY는 데이터베이스에서 수행
   • ORDER BY는 Application Server에서 실행

2-1 IF NOT ~ IS INITIAL.

IF NOT GT_ITAB[] IS INITIAL. 을 사용하였는데

때에 따라 이렇게 넣어줘야 할 때도 있지만

굳이 하위 FORM에서 이렇게 한 것은 리소스 낭비였다

때에 따라 사용 할 줄 알아야겠다.

2-2 MOVE-CORRESPONDING ~ TO ~

MOVE-CORRESPONDING IITEM TO GT_ITAB.

을 사용해서 IITEM에 있는 몇개의 컬럼을 ITAB으로 옮겼다.

물론 굉장히 편리하지만 이건 개발자만을 위한 편함이었다.

컬럼수가 어느정도 안된다면 사용하는 것을 자제하도록 하자.

READ 문에 KEY값을 주고 Binary Search를 했는데

READ TABLE CT_MSEG1 WITH KEY UPPER = GT_ITAB-MATNR
MATNR = GT_ITAB-IDNRK
BINARY SEARCH.

이런식으로 READ문을 날리고 이후에 SY-SUBRC = 0 이 되면 수량을 넣는 것이었는데...

SY-SUBRC가 4만 나오는 것이었다... 디버깅 하며 값을 각각각각 보는데 일치하게 값이 나오는데도

SY-SUBRC의 값은 4....

바보같이 DATA TYPE 때문인가도 고민해보고 하다...

결국 알아차린건

SORT :

를 하지 않아버리고 BINARY SEARCH를 해버렸다는거...

BINARY SEARCH... SORT.... 기억하기

바보같은실수 += 1

함께 읽기 좋은 글

m.cafe.daum.net/ABAP4/2m4n/115?q=D_q63L_X4PY8o0&

R/3 Architecture

• 세개의 Layer로 분류

1. Presentation Layer
   • 개인 컴퓨터
   • SAP GUI를 통해 데이터를 입력 및 조회
   • SAP GUI는 단지 터미널의 역할
2. Application Layer
   • 모든 프로그램은 Application Server에서 구성
   • Application Layer는 여러개의 Server와 하나의 Message Server로 구성
     • Message Server는 부하가 적은 서버에 사용자가 로그인 되도록 부하 분산 역할
   • OPEN SQL 사용시 Local Buffer가 데이터베이스까지 접근하지 않고 Local Buffer에서 데이터를 읽어옴
   • Dispather는 Work Process를 적절히 분배하는 역할
3. Databas Layer
   • SAP의 모든 데이터를 데이터베이스 테이블에 저장하는 계층
   • 시스템 변수, 모든 프로그램의 소스 코드, 트랜잭션 데이터 등 저장

기존 프로그램과 SAP 프로그램의 차이점

• JAVA ASP와 같은 프로그램과 달리 SAP는 일반 개발자에게 데이터베이스에 직접 접속하여 데이터를 수정하는 행위를 금지하고 있음.
• 데이터 조회 권한 까지 일반 개발자에게 제한
• 이러한 제한을 통해 무결성 일관성 안정성 투명성을 보장

ABAP 프로그램에 사용되는 오브젝트들 (Table, View, Structure, Types 등)을 ABAP Dictionary라고 부름

이러한 오브젝트들의 정보를 MetaData, Data Definition 또는 Schema라고 정의하여 데이터 구조를 정의하고 관리하는 역할을 ABAP Dictionary가 하게 됨

SQL

• SQL 은 DML, DDL, DCL로 구분된다.
• ABAP 프로그램의 OPEN SQL에서는 DML만 사용 가능

SQL에는 OPEN SQL과 NATIVE SQL이 있음

1. OPEN SQL
   • ABAP언어에서만 사용 됨
   • Database Interface를 통해 NATIVE SQL로 번역 됨
   • Local Buffer 사용 가능
   • DML 만 사용 가능
2. NATIVE SQL
   • OPEN SQL로 구현 할 수 없는 쿼리 사용시

SELECT 구문

SELECT <LINES> <COLUMNS> ...

1. Single Line
   • 하나의 라인 값을 읽어오고자 할 때
   • WHERE 조건에 유일한 키 값이 추가되어야 하는데 여러 개의 라인을 읽어오면 임의의 라인을 반환
2. Several Lines
   • 여러개 라인 값을 읽어오고자 할 때
   • DISTINCT 를 사용하면 중복 값 제외
   • INTO 구문의 결과가 저장되는 곳이 인터널 테이블이 아닌 필드나 Work Area(구조체)일 때에는 마지막에 ENDSELECT를 사용하여야 한다. 이 때 조건에 해당하는 값을 모두 읽어 올 때까지 LOOP를 수행한다.
     • SELECT ENDSELECT 구문은 수행 될때마다 Application Server와 Database 간의 인터페이스가 수행되어 조회 후 Loop 문보다 비효율적
3. AS(Alias)
4. 동적인 SELECT 구문

FROM 구문

• 하나 또는 여러개의 테이블을 Join 하고 조회 할 수 있다.
• Option
  • CLIENT SPECIFIED : 자동 CLIENT 설정 해제
  • BYPASSING BUFFER : BUFFER에서 값을 읽지 않음, BUFFERING이 설정되어 있더라도 바로 데이터베이스 테이블에서 SELECT 수행
  • UP TO n ROWS : SELECT 의 row 개수 제한

WHERE 구문

1. Interval 조건

   SELECT ... WHERE <s> [NOT ] BETWEEN <f 1> AND <f 2>

2. String 비교

   SELECT ... WHERE COL1 LIKE 'ABC%'. "*ABC 로 시작하는 조건 SELECT ... WHERE COL2 LIKE 'ABC_'. "*ABC 로 시작하는 4자리 조건

3. LIST VALUE

   SELECT ... WHERE 거주지 IN ('서울', '수원'). "*서울 OR 수원에 거주하는 (여러) 조건에 속한 값

4. FOR ALL ENTRIES

   SELECT ... FOR ALL ENTRIES IN <itab> WHERE <cond>
   • itab의 칼럽과 비교 대상 테이블의 칼럼 타입은 같아야 한다.
   • LIKE BETWEEN IN 과 같은 비교 구문 사용 불가
   • 중복된 값은 하나만 남는다. (Unique Key 기준)
   • itab이 NULL이면 모든 데이터를 읽는다.
   • itab의 수가 많으면 그만큼 효율이 떨어짐 ( 수만큼 select문 날림 )

   (주의사항 참조 : https://m.blog.naver.com/PostView.nhn?blogId=whiteme7&logNo=110132665367&proxyReferer=https:%2F%2Fwww.google.com%2F)

5. GROUPING 구문

   SELECT <f1> <f2> [OPTION(값)] <값>... GROUP BY <f1> <f2>
   • 값들의 정보를 요약하여 조회되게 함.
   • OPTION : AVG, COUNT, MAX, MIN, STDDEV, SUM, VARIANCE

6. GROUPING 조건 : HAVING

   • GROUP BY로 조회한 구문에 그룹의 조건 추가

7. SORT 구문

   • ORDER BY를 사용하여 기술된 컬럼 기준으로 정렬
   • ORDER BY 사용하지 않으면 임의로 정렬된 결과
   • ASSENDING, DESCENDING 구문으로 정렬 사용 가능

8. Subquery

   • where 조건에 또 다른 select문 추가하여 값을 제한 목적
   1. Scalar Subquery
      • 반드시 한 칼럼만을 반환해야 한다.
      • Nested Loop 방식
      • 실행되는 횟수는 row 수
      • 반복되는 코드나 유형의 테이블에서 효율적
   2. nonScalar Subquery
      • 결과가 존재하면 True 반환
      • 결과가 없다면 False 반환
      • EXISTS 구문으로 구현

구조체 ( Structure )

• 테이블과 비슷하지만 차이가 있다.
• 테이터의 유무 ( 테이블은 데이터 유, 구조체는 무 )
• 개발 편의성을 위함 → 동일구조 Internal Table을 반복 사용시
• 조회문에서 * 사용하면 성능 하락, 비효율적 → 구조체 사용하여 효율적으로 할 수 있다.

(출처 : http://egloos.zum.com/yhkim0614/v/1848428 )

( 출처 https://ljshappy.tistory.com/13 )

시스템변수 sy-datum과 sy-datlo의 차이점

• sy-datum은 System Time Zone에 설정된 시간
• sy-datlo은 User's Time Defalt Time 또는 사용자 프로파일에 설정된 Time Zone을 기준으로!

국내 기업의 경우에는 DATUM만 사용해도 크게 문제가 없다.

하지만 중국과 인도등 글로벌 업체의 예를 들면 같은 서버를 사용하는데 서버가 중국에 있다 라고 가정하면

동일 시점이라고 해도 시차에 의해 중국은 11시 15분 인도는 8시 45분이다.

그럼 인도에서 8시 45분에 기재한것이 DATUM을 사용하면 11시 15분으로 기재되게 되는데 이러면 항상 시차를 계산하고 염두해야 하는 경우가 생기기도 하고 이로 인해 혼동이 생길 수 있다.

그래서 글로벌적으로는 DATLO를 사용하는 경우가 발생하기도 한다.

위의 경우에 해당한다고 무조건 DATLO를 사용하는 것은 아니고 프로그램에 따라 혼용 될 수 있음에 유의하자

작은 따옴표 ' VS 그레이브 기호 `

Easy ABAP 2.0에 오기재 되어있는데 (참조 http://sapjoy.co.kr/?mid=BQNA&document_srl=92572 )

작은 따옴표 ' 을 사용하면 공백을 인식하지 못하고

그리이브기호 `을 사용하면 모든 공백을 인식한다.

데이터 타입에 대한 상세한 내용들이 많긴 하지만

주로 사용하는 방식이 정해져 있기에 2회차때 더 상세히 정리하기로 하였다.

변명이지만 오늘은 야근도 있었고, 퇴근 후 내일채움공제 관련 PPT를 만들어야 해서

많이 하지 못했다...

내일은 더 많이 하도록 노력해보자!

ABAP 프로그램은

• Data Type - 데이터의 타입 정의
• Data Variable ( Data Object ) - 데이터 타입을 참고하여 값을 저장하는 변수

가 존재

TYPES 구문을 사용하여 Data Type을 선언하면 해당 프로그램에서 사용만 가능하기에 Local Data Type이라고 부름 ( 지역변수 )

(보통 내가 짜는 프로그램들을 이미 다 타입들이 정의되어있어서 like 를 사용해서 Data만 정의함)

Data Object

• Data Variable은 실제 Data Object를 의미
• 프로그램이 실행되는 동안 메모리를 점유하는 물리적 단위

Data Type은 크게 3종류

1. Predefined ABAP Type
   • Kernel 레벨에서 정의된 기본 데이터 타입
   • C의 (c,f,l) 타입 처럼 이미 정의된 데이터 타입
2. Local Data Type in Program
   • Predefined ABAP Type을 조합하여 여러 필드가 추가된 Strurure 타입을 정의하여 사용 가능
3. Global Data Type in ABAP Dictionary
   • 모든 ABAP 프로그램에서 사용할 수 있는 TYPE
   • SE11에서 생성하는 ABAP Dictionary 오브젝트는 모든 프로그램에서 변수를 선언할 때 데이터 타입으로 사용 가능

Data Variable 선언

1. Predefined ABAP Type 선언

DATA : gv_num  TYPE i,
             gv_data TYPE d.

2. 프로그램의 Local Type을 이용하여 선언

*     로컬타입 선언부        
TYPE : BEGIN OF t_struct,
                    col1 TYPE c,
             END OF t_struct.

Data : gs_struct TYPE t_struct.

3. ABAP Dictionary 의 Type을 이용하여 변수 선언

DATA : gv_matnr TYPE mara-matnr.

ABAP 기본 문법

1. 문장은 마침표 기호로 마무리

   • WRITE gv_val.

2. 주석은 두가지

   • • 는 한 라인 전체 주석 처리
   • • 은 뒷부분 문자열 주석 처리

3. 문자열은 ' ' rlghfh cjfl

4. 명령어는 공백을 두고 처리

    gv_val='ABAP'. "은 X
    gv_val = 'ABAP "이와같이

ABAP 이름 규칙

1. ABAP Dictionary의 이름 규칙 = Z 혹은 Y로 시작

2. INSERT , APPEND와 같은 키워드 사용 금지

3. 개발리더 (컨설턴트) 가 정한 룰 따르자

4. 변수명은 _ 포함하여 30자

5. 변수의 앞 2자리는 범위와 데이터 유형을 나타내고

6. _와 마지막 단어는 어떠한 역할 하는지

    DATA : GT_SFLIGHT TYPE SFLIGHT. " 이와 같이!

   • 필드는 V or D
   • 구조체 S
   • 상수 C
   • 인터널테이블 T
   • 클래스 O
   • Range R
   • 데이터 참조변수 F

• 이름규직 점검은 T-CODE : SCI 실행해서 확인 가능
• 혹은 Program - Check - Code Inspector 에서 점검 가능

Package

• Development Class
• 프로그램과 같은 오브젝트를 기능별로 관리하고자
• Package의 기능
  1. 오브젝트 (프로그램 등) 의 구조화
  2. 오브젝트 기능을 모듈화
  3. 오브젝트를 기능별로 구별
• 모듈별로 프로그램 구분을 하게 됨
  • ex ) 영업은 ZSD, 생산은 ZPP와 같이...

Software Component

• Package들을 모아 한 세트로 관리하는 상위의 그룹
• 버전 별로 관리
• SAP Upgrade 또는 Patch를 적용 하도록 설계
• Software Componet > Package > Object에 할당되어 고객에게 배포-인도 됨
• Support Package를 적용하는 것은 Software Component 버전을 생성하여

Package Create

• T-CODE : SE21 또는 SPACKAGE 에서 패키지 생성

Transport Layer

• 개발과 테스트 작업을 여러 시스템으로 분산할 수 있는 환경 제공
• 오브젝트를 다른 시스템으로 전송하고 오브젝트의 변화와 관리를 기록하는 역할
• T-CODE : STMS 를 통해서 Transport layer와 전송 경로를 정의
• BC 관리자에게만 권한이 있고, 세팅함
• 전체 서버는 3개로 구분 됨
  • APT (개발)
    • ZAPT 경로 : 고객사에서 프로그램 개발 및 IMG 세팅 사항을 다른 서버로 전송할 때 사용
      • IMG (Implementation Guide)
        • Customizing에 사용되는 일반적인 Tool
        • 스탠다드 프로그램을 고객사 환경에 맞게 변경하여 적용 가능
        • T-CODE : SPRO
    • SAP 경로 : SAP에서 Support Package를 반영할 때 사용
  • APQ (테스트)
  • APP (운영)

CTS ( Change Request )

• CTS는 개발 서버에서 변경된 사항을 운영 서버에 반영하거나 고객 환경에 적합하도록 커스터마이징 하는 TOOL
• 보통의 서버 환경은 3개의 독립된 서버로 구성
  • DEV(개발) QAS(테스트) PRD(운영)
  • 하나의 서버에 클라이언트로 구분하는 경우도 있음
• CTS는 Repository(프로그램, 테이블 등) 의 버전을 관리하며 구성관리 TOOL로서의 역할도 수행
• 마치 GitHub과 비슷한 느낌?

Transport Organizer

• T-CODE : SE09
• CTS를 관리하는 프로그램

Request No 생성

• Request No는 실무에서 CR(Change Request), CTS NO와 같은 의미로 사용
• CR은 클라이언트에서 다른 클라이언트로 전송 가능
• CR은 시스템에서 다른 시스템의 클라이언트로 전송 가능

오브젝트들 Overwrite되며 문제 발생 가능하기에

Change Request를 반영할 때는 사용자가 시스템을 사용하지 않는 시간 권장

최악의 경우 운영 시스템 정지까지 발생할 수 있다.

NOTES

• SAP Standard에서 버그가 발생한다면 NOTES를 반영하여 해결 가능
• 버그 수정 뿐만 아니라 속도 개선, 기능 추가와 같은 솔루션도 제공
• 소규모 Upgrade라고 정의 가능
• T-CODE : SNOTE
• 개발자가 직접 스탠다드 수정시에는 Access Key 받아서 수정하면 됨