일반 구성

이 섹션에서는 v5.11 또는 v6.02에서 마이그레이션하는 경우 Adobe Campaign v7에서 수행할 구성에 대해 자세히 설명합니다.

또한

  • v5.11에서 마이그레이션하는 경우 v5.11의 특정 구성 섹션에 자세히 설명된 구성도 완료해야 합니다.
  • v6.02에서 마이그레이션하는 경우 v6.02🔗 섹션의 특정 구성에 자세히 설명된 구성도 완료해야 합니다.

시간대

다중 시간대 모드

v6.02에서 "다중 시간대" 모드는 PostgreSQL 데이터베이스 엔진에만 사용할 수 있었습니다. 이제 어떤 유형의 데이터베이스 엔진을 사용하든 상관없이 제공됩니다. 기본 시간대를 "다중 시간대" 기준으로 변환하는 것이 좋습니다.

TIMESTAMP WITH TIMEZONE 모드를 사용하려면 -userTimestamptz:1 옵션을 업그레이드 후 명령줄에 추가해야 합니다.

중요

-usetimestamptz:1 매개 변수를 호환되지 않는 데이터베이스 엔진과 함께 사용하면 데이터베이스가 손상되며 데이터베이스 백업을 복원한 다음 위의 명령을 다시 실행해야 합니다.

노트

콘솔(Administration > Platform > Options > WdbcTimeZone 노드)을 통해 마이그레이션 후 시간대를 변경할 수 있습니다.

시간대 관리에 대한 자세한 내용은 이 섹션을 참조하십시오.

Oracle

업그레이드 후 ORA 01805 오류가 발생하면 애플리케이션 서버와 데이터베이스 서버 사이의 Oracle 시간대 파일이 동기화되지 않은 것입니다. 다시 동기화하려면 다음 단계를 수행합니다.

  1. 사용된 시간대 파일을 식별하려면 다음 명령을 실행합니다.

    select * from v$timezone_file
    

    시간대 파일은 일반적으로 ORACLE_HOME/oracore/zoneinfo/ 폴더에 있습니다.

  2. 표준 시간대 파일이 두 서버 모두에서 동일한지 확인합니다.

자세한 내용은 다음을 참조하십시오. https://docs.oracle.com/cd/E11882_01/server.112/e10729/ch4datetime.htm#NLSPG004

클라이언트와 서버 간에 시간대가 잘못 정렬되면 일부 지연이 발생할 수 있습니다. 클라이언트와 서버 측에서 동일한 버전의 Oracle 라이브러리를 사용하는 것이 좋습니다. 두 시간대는 동일해야 합니다.

양측이 동일한 시간대에 있는지 확인하려면:

  1. 다음 명령을 실행하여 클라이언트 측에서 시간대 파일의 버전을 확인합니다.

    genezi -v
    

    genezi는 $ORACLE_HOME/bin 저장소에 있는 바이너리입니다.

  2. 다음 명령을 실행하여 서버 측에서 시간대 파일의 버전을 확인합니다.

    select * from v$timezone_file
    
  3. 클라이언트 측에서 시간대 파일을 변경하려면 ORA_TZFILE 환경 변수를 사용하십시오.

보안

보안 영역

중요

보안상의 이유로 기본적으로 Adobe Campaign 플랫폼에 더 이상 액세스할 수 없습니다. 보안 영역을 구성해야 하므로 운영자 IP 주소를 수집합니다.

Adobe Campaign v7에는 보안 영역​의 개념이 포함되어 있습니다. 인스턴스에 로그온하려면 각 사용자가 영역에 연결되어 있어야 하며 사용자의 IP 주소가 보안 영역에 정의된 주소 또는 주소 범위에 포함되어야 합니다. 보안 영역 구성은 Adobe Campaign 서버 구성 파일에서 수행할 수 있습니다. 사용자가 연결된 보안 영역을 콘솔에 정의해야 합니다(Administration > Access management > Operators).

마이그레이션 전에 네트워크 관리자에게 마이그레이션 후 활성화할 보안 영역을 정의할 수 있도록 도움을 요청하십시오.

업그레이드 후 (서버를 다시 시작하기 전에) 보안 영역을 구성해야 합니다.

보안 영역 구성은 이 섹션에 있습니다.

사용자 암호

v7에서 내부admin 연산자 연결은 암호로 보호해야 합니다. 마이그레이션​전에 이러한 계정 및 모든 운영자 계정​에 암호를 할당하는 것이 좋습니다. internal​에 대한 암호를 지정하지 않은 경우 연결할 수 없습니다. internal​에 암호를 할당하려면 다음 명령을 입력합니다.

nlserver config -internalpassword
중요

내부 암호는 모든 추적 서버에 대해 동일해야 합니다. 자세한 정보는 이 섹션이 섹션을 참조하십시오.

v7의 새로운 기능

  • 권한이 없는 사용자는 더 이상 Adobe Campaign에 연결할 수 없습니다. 예를 들어 connect​라는 권한을 만들어 수동으로 해당 권한을 추가해야 합니다.

    이 수정의 영향을 받는 사용자는 업그레이드 후 식별 및 나열됩니다.

  • 암호가 비어 있으면 추적이 더 이상 작동하지 않습니다. 이러한 경우 오류 메시지가 사용자에게 알리고 다시 구성할 것을 요청합니다.

  • 사용자 암호는 더 이상 xtk:sessionInfo 스키마에 저장되지 않습니다.

  • 이제 xtk:builder:EvaluateJavaScriptxtk:builder:EvaluateJavaScriptTemplate 함수를 사용하려면 관리 권한이 필요합니다.

특정 기본 제공 스키마가 수정되었으며 이제 admin 권한이 있는 연산자에 대한 쓰기 액세스 권한만 사용하여 기본적으로 액세스할 수 있습니다.

  • ncm:게시
  • nl:모니터링
  • nms:달력
  • xtk:builder
  • xtk:연결
  • xtk:dbInit
  • xtk:entityBackupNew
  • xtk:entityBackupOriginal
  • xtk:entityOriginal
  • xtk:form
  • xtk:funcList
  • xtk:fusion
  • xtk:image
  • xtk:javascript
  • xtk:jssp
  • xtk:jst
  • xtk:navtree
  • xtk:operatorGroup
  • xtk:package
  • xtk:queryDef
  • xtk:resourceMenu
  • xtk:rights
  • xtk:스키마
  • xtk:scriptContext
  • xtk:specFile
  • xtk:sql
  • xtk:sqlSchema
  • xtk:srcSchema
  • xtk:문자열
  • xtk:xslt

Sessiontoken 매개 변수

v5에서 sessiontoken 매개 변수가 두 클라이언트 측에서 작동했습니다(개요 유형 화면, 링크 편집기 등 목록). 및 서버측(웹 애플리케이션, 보고서, jsp, jssp 등)은 v7에서는 서버 측에서만 작동합니다. v5에서 전체 기능으로 돌아가려면 이 매개 변수를 사용하여 링크를 수정하고 연결 페이지를 통과해야 합니다.

링크 예:

/view/recipientOverview?__sessiontoken=<trusted login>

연결 페이지를 사용하는 새 링크:

/nl/jsp/logon.jsp?login=<trusted login>&action=submit&target=/view/recipientOverview
중요

신뢰할 수 있는 IP 마스크와 연결된 연산자를 사용하는 경우, 최소 권한이 있고 sessionTokenOnly 모드의 보안 영역에 있는지 확인하십시오.

SQL 함수

알 수 없는 SQL 함수 호출이 더 이상 서버에 자연스럽게 전송되지 않습니다. 현재 모든 SQL 함수를 xtk:funcList 스키마에 추가해야 합니다(자세한 내용은 이 섹션 참조). 마이그레이션할 때 업그레이드 후 이전 선언되지 않은 SQL 함수와 호환성을 유지할 수 있는 옵션이 추가됩니다. 이러한 함수를 계속 사용하려면 XtkPassUnknownSQLFunctionsToRDBMS 옵션이 실제로 Administration > Platform > Options 노드 수준에서 정의되었는지 확인합니다.

중요

보안 위험으로 인해 이 옵션을 사용하지 않는 것이 좋습니다.

JSSP

예를 들어 웹 앱에서 보안 영역에서 수행된 구성에 관계없이 HTTP 프로토콜(HTTPS 아님)을 통해 특정 페이지에 대한 액세스를 승인하려면 해당 릴레이 규칙에 httpAllowed="true" 매개 변수를 지정해야 합니다.

익명 JSSP를 사용하는 경우 JSSP(serverConf.xml 파일)에 대한 릴레이 규칙에 httpAllowed="true" 매개 변수를 추가해야 합니다.

예제:

<url IPMask="" deny="" hostMask="" httpAllowed="true" relayHost="true" relayPath="true"
           status="blacklist" targetUrl="https://localhost:8080" timeout="" urlPath="*/cus/myPublicPage.jssp"/>

구문

JavaScript

Adobe Campaign v7에는 최신 JavaScript 인터프리터가 통합됩니다. 그러나 이 업데이트로 인해 특정 스크립트가 작동하지 않을 수 있습니다. 이전 엔진이 보다 더 유연했기 때문에, 어떤 구문들은 더 이상 새로운 버전의 엔진과 함께 작동하지 않을 것이다.

이제 myObject.@attribute 구문은 XML 개체에만 유효합니다. 이 구문은 게재 및 컨텐츠 관리를 개인화하는 데 사용할 수 있습니다. 비 XML 개체에서 이 유형의 구문을 사용한 경우 개인화 기능이 더 이상 작동하지 않습니다.

다른 모든 개체 유형의 경우 구문은 이제 myObject["attribute"]​입니다. 예를 들어, 다음 구문을 사용한 비 XML 객체입니다. employee.@sn 는 이제 다음 구문을 사용해야 합니다. [!UICONTROL employee["sn"]]

  • 이전 구문:

    employee.@sn
    
  • 새 구문:

    employee["sn"]
    

XML 개체에서 값을 변경하려면 먼저 XML 노드를 추가하기 전에 값을 업데이트해야 합니다.

  • 이전 JavaScript 코드:

    var cellStyle = node.style.copy();
    this.styles.appendChild(cellStyle);
    cellStyle.@width = column.@width;
    
  • 새 JavaScript 코드:

    var cellStyle = node.style.copy();
    cellStyle.@width = column.@width;
    this.styles.appendChild(cellStyle);
    

더 이상 XML 특성을 테이블 키로 사용할 수 없습니다.

  • 이전 구문:

    if(serverForm.activities[ctx.activityHistory.activity[0].@name].type !="end")
    
  • 새 구문:

    if(serverForm.activities[String(ctx.activityHistory.activity[0].@name)].type !="end"
    

SQLData

인스턴스 보안을 강화하기 위해 SQLData 기반 구문을 대체하기 위해 Adobe Campaign v7에 새로운 구문이 도입되었습니다. 이 구문과 함께 이러한 코드 요소를 사용하는 경우 이를 수정해야 합니다. 관련 주요 요소는 다음과 같습니다.

  • 하위 쿼리별 필터링: 새 구문은 <subQuery> 요소를 기반으로 하위 쿼리를 정의합니다
  • 합계: 새 구문은 "aggregate function(collection)"입니다.
  • 가입별 필터링: 새 구문은 [schemaName:alias:xPath]입니다.

queryDef(xtk:queryDef) 스키마가 수정되었습니다.

  • <subQuery> 요소를 사용하여 SQLData에 포함된 SELECT를 바꿀 수 있습니다
  • @setOperator 속성에 대해 "IN" 및 "NOT IN" 이라는 두 개의 새 값이 도입되었습니다
  • <node> 요소의 하위 요소인 새 <where> 요소: 이렇게 하면 SELECT에서 "하위 선택"을 수행할 수 있습니다.

"@expr" 속성을 사용하면 SQLData가 있을 수 있습니다. 다음 용어를 검색할 수 있습니다. "SQLData", "aliasSqlTable", "sql".

Adobe Campaign v7 인스턴스는 기본적으로 안전합니다. 보안은 serverConf.xml 파일에 있는 보안 영역의 정의 측면에서 제공됩니다. allowSQLInjection 특성은 SQL 구문 보안을 관리합니다.

업그레이드 후 실행 중에 SQLData 오류가 발생하는 경우 코드를 다시 작성할 수 있도록 SQLData 기반 동기화를 일시적으로 허용하려면 이 속성을 수정해야 합니다. 이렇게 하려면 serverConf.xml 파일에서 다음 옵션을 변경해야 합니다.

allowSQLInjection="true"

따라서 다음 명령을 사용하여 업그레이드 후 를 다시 시작합니다.

nlserver config -postupgrade -instance:<instance_name> -force

보안 영역을 구성해야 합니다( 보안 참조). 다음 옵션을 변경하여 보안을 다시 활성화해야 합니다.

allowSQLInjection="false"

아래에서 이전 구문과 새 구문 간에 비교 예를 확인할 수 있습니다.

하위 쿼리별 필터링

  • 이전 구문:

    <condition expr="@id NOT IN ([SQLDATA[SELECT iOperatorId FROM XtkOperatorGroup WHERE iGroupId = $(../@owner-id)]])" enabledIf="$(/ignored/@ownerType)=1"/>
    
  • 새 구문:

    <condition setOperator="NOT IN" expr="@id" enabledIf="$(/ignored/@ownerType)=1">
      <subQuery schema="xtk:operatorGroup">
         <select>
           <node expr="[@operator-id]" />
         </select>
         <where>
           <condition expr="[@group-id]=$long(../@owner-id)"/>
         </where>
       </subQuery>
    </condition>
    
  • 이전 구문:

    <queryFilter name="dupEmail" label="Emails duplicated in the folder" schema="nms:recipient">
        <where>
          <condition sql="sEmail in (select sEmail from nmsRecipient where iFolderId=$(folderId) group by sEmail having count(sEmail)>1)" internalId="1"/>
        </where>
        <folder _operation="none" name="nmsSegment"/>
      </queryFilter>
    
  • 새 구문:

    <queryFilter name="dupEmail" label=" Emails duplicated in the folder " schema="nms:recipient">
        <where>
          <condition expr="@email" setOperator="IN" internalId="1">
            <subQuery schema="nms:recipient">
              <select><node expr="@email"/></select>
              <where><condition expr="[@folder-id]=$(folderId)"/></where>
              <groupBy><node expr="@email"/></groupBy>
              <having><condition expr="count(@email)>1"/></having>
            </subQuery>
          </condition>
        </where>
        <folder _operation="none" name="nmsSegment"/>
      </queryFilter>
    

합계

집계 함수(컬렉션)

  • 이전 구문:

    <node sql="(select count(*) from NmsNewsgroup WHERE O0.iOperationId=iOperationId)" alias="@nbMessages"/>
    
  • 새 구문:

    <node expr="count([newsgroup/@id])" alias="../@nbMessages"/>
    
    노트

    조인트는 자동으로 집계 기능을 위해 수행됩니다. WHERE O0.iOperationId=iOperationId 조건을 더 이상 지정할 필요가 없습니다.

    더 이상 "count(*)" 함수를 사용할 수 없습니다. "countall()"을 사용해야 합니다.

  • 이전 구문:

    <node sql="(select Sum(iToDeliver) from NmsDelivery WHERE O0.iOperationId=iOperationId AND iSandboxMode=0 AND iState>=45)" alias="@nbMessages"/>
    
  • 새 구문:

    <node expr="Sum([delivery-linkedDelivery/properties/@toDeliver])" alias= "../@sumToDeliver">
                      <where><condition expr="[validation/@sandboxMode]=0 AND @state>=45" /></where></node>
    

조인으로 필터

[schemaName:alias:xPath]

별칭은 선택 사항입니다

  • 이전 구문:

    <condition expr={"[" + joinPart.destination.nodePath + "] = [SQLDATA[W." + joinPart.source.SQLName + "]]"}
                                             aliasSqlTable={nodeSchemaRoot.SQLTable + " W"}/>
    
  • 새 구문:

    <condition expr={"[" + joinPart.destination.nodePath + "] = [" + nodeSchema.id + ":" + joinPart.source.nodePath + "]]"}/>
    

팁과 트릭

<subQuery> 요소에서 기본 <queryDef>의 "field" 필드를 참조합니다. 요소를 사용하려면 다음 구문을 사용하십시오. [../@field]

예제:

<queryDef operation="select" schema="xtk:jobLog" startPath="/" xtkschema="xtk:queryDef">
  <select>
    <node expr="[job/@pid]" alias="@pid"/>
    <node expr="@id" ordered="true"/>
    <node expr="@logType"/>
  </select>
  <where>
    <condition expr="[@job-id]=99"/>
    <condition expr="@logType" setOperator="IN">
      <subQuery schema="xtk:jobLog">
        <select><node expr="@logType"/></select>
        <where><condition expr="[@job-id]=[../job/@id]"/></where>
        <groupBy><node expr="@logType"/></groupBy>
        <having><condition expr="count(@logType)>1"/></having>
      </subQuery>
    </condition>
  </where>
</queryDef>

충돌

마이그레이션은 업그레이드 후 수행되며 충돌이 보고서, 양식 또는 웹 애플리케이션에 표시될 수 있습니다. 콘솔에서 이러한 충돌을 해결할 수 있습니다.

리소스 동기화 후 postupgrade 명령을 사용하여 동기화가 오류나 경고를 생성하는지 감지할 수 있습니다.

동기화 결과 보기

동기화 결과는 다음 두 가지 방법으로 볼 수 있습니다.

  • 명령줄 인터페이스에서 트리플 V자형 화살표 >​에 의해 오류가 발생하고 동기화가 자동으로 중지됩니다. 경고는 이중 V자형 화살표 ​에 의해 구체화되며 동기화가 완료되면 해결되어야 합니다. 업그레이드 후 종료 시 명령 프롬프트에 요약이 표시됩니다. 예제:

    2013-04-09 07:48:39.749Z        00002E7A          1     info    log     =========Summary of the update==========
    2013-04-09 07:48:39.749Z        00002E7A          1     info    log     test instance, 6 warning(s) and 0 error(s) during the update.
    2013-04-09 07:48:39.749Z        00002E7A          1     warning log     The document with identifier 'mobileAppDeliveryFeedback' and type 'xtk:report' is in conflict with the new version.
    2013-04-09 07:48:39.749Z        00002E7A          1     warning log     The document with identifier 'opensByUserAgent' and type 'xtk:report' is in conflict with the new version.
    2013-04-09 07:48:39.750Z        00002E7A          1     warning log     The document with identifier 'deliveryValidation' and type 'nms:webApp' is in conflict with the new version.
    2013-04-09 07:48:39.750Z        00002E7A          1     warning log     Document of identifier 'nms:includeView' and type 'xtk:srcSchema' updated in the database and found in the file system. You will have to merge the two versions manually.
    

    경고에서 리소스 충돌이 발생할 경우 이를 해결하기 위해 운영자 주의가 필요합니다.

  • 업그레이드 후 postupgrade_<server version number>_time>.log 파일에 동기화 결과가 포함되어 있습니다. 기본적으로 다음 디렉토리에서 사용할 수 있습니다. 설치 디렉토리/var/<instance>postupgrade 오류 및 경고는 errorwarning 특성으로 표시됩니다.

충돌 해결

충돌을 해결하려면 고급 연산자와 '관리자' 권한이 부여된 작업자만 수행해야 합니다.

충돌을 해결하려면 다음 프로세스를 적용합니다.

  1. Adobe Campaign 트리 구조에서 커서를 Administration > Configuration > Package management > Edit conflicts 위에 놓습니다.
  2. 목록에서 해결할 충돌을 선택합니다.

갈등을 해결하는 방법에는 세 가지가 있습니다.

  • Declared as resolved: 미리 운영자 개입이 필요합니다.

  • Accept the new version: 사용자가 Adobe Campaign과 함께 제공한 리소스를 변경하지 않은 경우 권장합니다.

  • Keep the current version: 은(는) 업데이트가 거부됨을 의미합니다.

    중요

    이 해결 모드를 선택하면 새 버전에서 패치가 손실될 수 있습니다. 따라서 이 옵션은 전문가 연산자만 사용하거나 예약하지 않는 것이 좋습니다.

충돌을 수동으로 해결하도록 선택한 경우 다음과 같이 진행하십시오.

  1. 창의 아래 섹션에서 _conflict_ string​을 검색하여 충돌이 있는 엔티티를 찾습니다. 새 버전과 함께 설치된 엔터티에 new 인수가 포함되어 있습니다. 이전 버전과 일치하는 엔터티에 cus 인수가 포함되어 있습니다.

  2. 유지하지 않을 버전을 삭제합니다. 유지하고 있는 엔터티의 _conflict_argument_ string​을 삭제합니다.

  3. 해결할 충돌로 이동합니다. Actions 아이콘을 클릭하고 Declare as resolved 을 선택합니다.

  4. 변경 사항을 저장합니다. 이제 충돌이 해결되었습니다.

Tomcat

Adobe Campaign v7의 통합 Tomcat 서버가 버전을 변경했습니다. 따라서 설치 폴더(tomcat-6)도 변경되었습니다(tomcat 7). 업그레이드 후 경로가 업데이트된 폴더(serverConf.xml 파일)에 링크되는지 확인합니다.

$(XTK_INSTALL_DIR)/tomcat-8/bin/bootstrap.jar 
$(XTK_INSTALL_DIR)/tomcat-8/bin/tomcat-juli.jar
$(XTK_INSTALL_DIR)/tomcat-8/lib/tomcat-util.jar
$(XTK_INSTALL_DIR)/tomcat-8/lib/tomcat-api.jar
$(XTK_INSTALL_DIR)/tomcat-8/lib/servlet-api.jar
$(XTK_INSTALL_DIR)/tomcat-8/lib/jsp-api.jar
$(XTK_INSTALL_DIR)/tomcat-8/lib/el-api.jar

상호 작용

필수 구성 요소

업그레이드 후 v7에 더 이상 존재하지 않는 6.02에서 모든 스키마 참조를 삭제해야 합니다.

  • nms:emailOfferView
  • nms:webOfferView
  • nms:callCenterOfferView
  • nms:mobileOfferView
  • nms:paperOfferView

오퍼 콘텐츠

v7에서 오퍼 컨텐츠가 이동되었습니다. v6.02에서 컨텐츠는 각 표현 스키마(nms:emailOfferView)에 있었습니다. v7에서 이제 컨텐츠가 오퍼 스키마에 있습니다. 따라서 업그레이드 후 컨텐츠가 인터페이스에 표시되지 않습니다. 업그레이드 후 오퍼 컨텐츠를 다시 만들거나 표현 스키마에서 오퍼 스키마로 컨텐츠를 자동으로 이동하는 스크립트를 개발해야 합니다.

중요

마이그레이션 후 구성된 오퍼를 사용하는 일부 게재를 전송해야 하는 경우에는 v7에서 이러한 모든 게재를 삭제하고 다시 만들어야 합니다. 이 작업을 수행할 수 없다면 "호환성 모드"가 제공됩니다. Interaction v7의 모든 새로운 기능을 활용하지는 않으므로 이 모드를 사용하지 않는 것이 좋습니다. 이것은 실제 6.1 마이그레이션 전에 진행 중인 캠페인을 완료할 수 있는 전환 모드입니다. 이 모드에 대한 자세한 내용은 문의하십시오.

이동 스크립트(interactionTo610_full_XX.js)의 예는 Adobe Campaign v7 폴더 내의 마이그레이션 폴더에서 사용할 수 있습니다. 이 파일은 오퍼당 단일 이메일 표현(htmlSourcetextSource 필드)을 사용하는 클라이언트에 대한 스크립트의 예를 보여줍니다. NmsEmailOfferView 테이블에 있던 컨텐츠가 오퍼 테이블로 이동되었습니다.

노트

이 스크립트를 사용하면 "컨텐츠 관리" 및 "렌더링 함수" 옵션을 사용할 수 없습니다. 이러한 기능을 활용하려면 카탈로그 오퍼, 특히 오퍼 콘텐츠 및 구성 공간을 재고해야 합니다.

loadLibrary("/nl/core/shared/nl.js");

NL.require("/nl/core/shared/xtk.js");

// 1. Restore old emailOfferView schema
logInfo("Restoring old emailOfferView schema");
var oldOfferViewSchemas = <entities schema="xtk:srcSchema"/>;

oldOfferViewSchemas.appendChild(
  <srcSchema img="nms:offerView.png"
             label="Email offer representations"
             labelSingular="Email offer representation"
             name="emailOfferView" namespace="nlmig"
             genAccessors="false" implements="xtk:persist">
    <element name="emailOfferView" template="nms:offerView" sqltable="NmsEmailOfferView">
      <element name="offer" revLabel="Email representation" revIntegrity="owncopy"/>
      <element   name="htmlSource"      type="html" label="HTML content"  xml="true"/>
      <element   name="textSource"      type="CDATA" label="Text content" xml="true"/>
      <element   name="htmlSource_jst"  type="CDATA" label="HTML script"  desc="HTML content calculation script."  xml="true" advanced="true"/>
      <element   name="textSource_jst"  type="CDATA" label="Text script" desc="Text content calculation script." xml="true" advanced="true"/>
    </element>
  </srcSchema>);

var oldOfferViewsPkg = <builder><package buildNumber="*">{oldOfferViewSchemas}</package></builder>;
xtk.builder.InstallPackage(oldOfferViewsPkg);

// 2. Migrate data from old emailOfferView table to nms:offer
logInfo("Moving data from old EmailOfferView table to NmsOffer");
var OFFER_STATUS_VALIDATED = 3;

var queryDef = xtk.queryDef.create(
  <queryDef operation="select" schema="nlmig:emailOfferView">
    <select>
      <node expr="[@offer-id]"/>
      <node expr="[@space-id]"/>
      <node expr="htmlSource_jst"/>
      <node expr="textSource_jst"/>
    </select>
  </queryDef>);
var res = queryDef.ExecuteQuery();

var processedOffers = {};
for each( var emailOfferView in res.emailOfferView )
{
  if( processedOffers[String(emailOfferView.@["offer-id"])] != undefined )
  {
    logWarning("Found 2 or more eff fffffmail representations for offer " + String(emailOfferView.@["offer-id"]) + ". Only keep the first one here.");
    continue;
  }
  xtk.session.Write(
    <offer id={emailOfferView.@["offer-id"]} status={OFFER_STATUS_VALIDATED} xtkschema="nms:offer">
      <view>
        {emailOfferView.mdSource_jst}
        {emailOfferView.textSource_jst}
      </view>
    </offer>
  );
  processedOffers[String(emailOfferView.@["offer-id"])] = 1;
}

// 3. Get rid of emailOfferView schema now that data has been moved.
logInfo("Deleting EmailOfferView schema");
xtk.session.Write(<srcSchema xtkschema="xtk:srcSchema" name="emailOfferView" namespace="nlmig" _operation="delete"/>);

logInfo("Done");

테스트 및 구성

환경이 한 개만 있는 경우 오퍼 컨텐츠를 이동한 후 따라야 하는 절차는 다음과 같습니다. 이 경우 "ENV"를 예로 들어 보겠습니다.

  1. 모든 "ENV" 환경에서 사용 중인 필드 목록을 업데이트합니다. 예를 들어 htmlSource​만 사용하는 오퍼 공간의 경우 view/htmlSource​을 추가해야 합니다.

  2. General 탭 내의 Type of Environment 필드에서 Live​를 선택합니다.

  3. 디자인 환경(예: "ENV_DESIGN")을 만들고 ENV 온라인 환경에 연결합니다.

  4. 모든 "ENV" 환경 오퍼 공간(마우스 오른쪽 단추 클릭 > Actions > Deploy)을 배포하고 "ENV_DESIGN" 환경을 선택합니다.

  5. 모든 "ENV" 환경 오퍼에 대해 동일하게 수행합니다.

  6. 모든 환경을 활성화하면 관련 채널에서 "ENV_DESIGN"을 제공합니다.

  7. 오퍼를 라이브로 만드는 테스트를 수행합니다. 문제가 발생하지 않는 경우 최신 워크플로우 작업 Offer notification(offerMgt)에서 보류 중인 작업을 실행하여 모든 오퍼를 실시간으로 생성하십시오.

  8. 포괄적인 테스트를 수행합니다.

    노트

    온라인 카테고리 및 오퍼의 이름은 라이브로 전환된 후 수정됩니다. 수신 채널에서 오퍼 및 카테고리에 대한 모든 참조를 업데이트합니다.

보고서

표준 보고서

현재 모든 표준 보고서는 렌더링 엔진 v6.x를 사용합니다. 이러한 보고서에 JavaScript를 추가한 경우 특정 요소가 더 이상 작동하지 않을 수 있습니다. 실제로 이전 버전의 JavaScript는 v6.x 렌더링 엔진과 호환되지 않습니다. 따라서 JavaScript 코드를 확인하고 나중에 조정해야 합니다. 모든 보고서, 특히 내보내기 기능을 테스트해야 합니다.

개인화된 보고서

새로운 보고서 기능을 활용하려면 보고서를 다시 게시해야 합니다. 이렇게 하려면 보고서 Properties​을 편집하고 Rendering​을(를) 클릭하고 v.6.x 렌더링 엔진을 선택합니다. 이 경우 모든 스크립트를 확인하고 필요한 경우 스크립트를 변경합니다. PDF 내보내기와 관련하여 Open Office용 특정 스크립트를 추가한 경우 새 PDF 내보내기 엔진(PhantomJS)에서 더 이상 작동하지 않습니다.

웹 애플리케이션

다음 두 가지 웹 애플리케이션 제품군이 있습니다.

  • 식별된 웹 애플리케이션(함께 확인, 승인 양식, 외부 내부 개발),
  • 익명의 웹 애플리케이션(웹 또는 설문 조사 양식)

식별된 웹 애플리케이션

보고서(자세히 알아보기)와 마찬가지로 JavaScript를 추가한 경우 필요한 경우 확인하고 조정해야 합니다. v7 파란색 배너를 사용하려면(파란색 탭 포함) 웹 애플리케이션을 다시 게시해야 합니다. JavaScript 코드가 작동하는 경우 v6.x 렌더링 엔진을 선택할 수 있습니다. 그렇지 않은 경우 코드를 조정하는 동안 v6.0 렌더링 엔진을 사용한 다음 v6.x 렌더링 엔진을 사용할 수 있습니다.

노트

렌더링 엔진을 선택하는 단계는 보고서를 선택하는 단계와 동일합니다. 개인화된 보고서를 참조하십시오.

웹 애플리케이션 연결 방법이 v7에서 변경되었습니다. 식별된 웹 응용 프로그램에서 연결 문제가 발생하면 serverConf.xml 파일에서 allowUserPasswordsessionTokenOnly 옵션을 일시적으로 활성화해야 합니다. 업그레이드 후 다음 옵션 값을 수정합니다.

allowUserPassword="true"
sessionTokenOnly="true"

따라서 다음 명령을 사용하여 업그레이드 후 를 다시 시작합니다.

nlserver config -postupgrade -instance:<instance_name> -force

웹 애플리케이션을 게시하기 전에 v6.x 렌더링 엔진에서 테스트합니다. 그런 다음 이 두 옵션을 비활성화합니다.

allowUserPassword="false"
sessionTokenOnly="false"

익명의 웹 애플리케이션

문제가 발생하면 웹 애플리케이션을 다시 게시합니다. 문제가 지속되면 v6.0 렌더링 엔진을 선택할 수 있습니다. JavaScript를 추가하지 않은 경우 v6.x 렌더링 엔진을 선택하고 새로운 기능을 활용할 수 있습니다.

노트

렌더링 엔진을 선택하는 단계는 보고서를 선택하는 단계와 동일합니다. 개인화된 보고서를 참조하십시오.

Red-Hat

v6.02 또는 v5.11에서 기본 제공 스키마가 삭제된 경우 업그레이드 후 스키마를 더 이상 편집할 수 없을 수 있습니다. 이렇게 되면 다음 명령을 실행합니다.

su - neolane
nlserver config -postupgrade -instance:<instance name> -force

이 페이지에서는