2018년 2월 20일 화요일

사이트코어 Config 파일 패치하기

우선, .NET 개발자라면은 WebConfig.config 또는 App 폴더안의 세팅파일들이 어플리케이션에서 어떤 중요한 역할을 하지는 기본적으로 알고있을것이다.
개발자들은 Configuration 파일을 통하여 어플리케이션을 Recompile 없이 변경할수 있으며, 사이트코어 역시 모듈 또는 기능 별로 많은 .config 파일을 파일시스템에 놓아둔다.

사이트코어는 버전 9를 릴리즈하면서, App_Config 폴더안의 파일 스트럭쳐를 폴더 별로 Organize 하였으면, 이번에는 어떻게 config 파일들을 수정하는지 알아보도록 하겠다.
.config 파일의 기본형식은 아시다시피, XML 파일의 형식이며 기본적이 구조는 아래와 같다.

1
2
3
4
5
<?xml version="1.0" encoding="utf-8"?>
<configuration>
    <sitecore>
    </sitecore>
</configuration>

보통 .Config 파일을 수정할때 해당 파일에 가서 변경하고 싶은 Node 또는 Value를 수정하는데, 사이트코어는 새로운 패치 파일을 만들어 변경 하는것을 선호한다.
예를 들어, Sitecore.config 파일안의 특정한 Node를 변경 또는 수정을 하고싶다면, WebRoot/App_Config 의 새로운 폴더 (예, 폴도명 zzz.custom)를 만들고, Configuration 노드에 XML Set Namespace를 추가하여 아래와 같은 패치파일을 만들수있다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
<!-- 기존 세팅 Sitecore.Config 파일 -->
<sitecore >
    <settings>
        <!--  AUTOMATIC UNLOCK ON SAVED
                If true, the a saved item is automatically unlocked after
                saving.
        -->
        <setting name="AutomaticUnlockOnSaved" value="false"/>
    </settings>
</sitecore>


 1
 2
 3
 4
 5
 6
 7
 8
 9
10
<!-- 패치 파일 /App_config/zzz.Custom/Sitecore.Custom.config -->
<?xml version="1.0" encoding="UTF-8"?>
<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/" xmlns:set="http://www.sitecore.net/xmlconfig/set/">
    <sitecore >
        <settings>
            <!--  Original Setting from Sitecore.config -->
            <setting name="AutomaticUnlockOnSaved" set:value="true"/>
        </settings>
    </sitecore>
</configuration>

해당 업데이트를 "http(s)://website/sitecore/admin/showconfig.aspx" 페이지에서 확인을 하면, 패치되어진 값을 볼수가있다.





이런 형식으로 패치파일을 이용하면 차후 시스템 및 어플리케이션 조금 더 효율적으로 관리 및 유지할수있으며, 시스템을 초기화하는데도 용이하다.

*참고로 사이트코어를 config 파일들을 A-Z 순서대로 서칭하며 폴더안에 다른 폴더들과 파일들이 같이 존재한다면, 파일을 먼저 A-Z 순으로 패치하고, 다음으로 폴더순으로 패치하기위한 서칭을 시작한다.

2018년 1월 23일 화요일

Sitecore Migration - Azure Toolkit Error

이전 포스트에 얘기한것 처럼, 회사에서 Sitecore On-Prem을 Azure로 Migration 진행중이다.

먼저, 기존 On-Prem에 사용하던 데이타 (Sitecore 8.0 U5)를 새로운 버전 (Sitecore 9.0.0) 으로 Migration을 해야하는데 서버 및 데이타베이스 환경이 틀리다보니, 기존의 데이타 Deployment Package를 생성하여야한다. Azure Deployment Package는 사이트코어의 Azure Deployment Toolkit를 이용하여 생성할수있는데, 그 이전에 로컬환경에 Sitecore 9.0 (XP0)을 설치하고 기존 데이터를 Sitecore Expression Migration Tool 3.1을 사용하여 로컬 Siteocre 9.0로 Migration 한다. 로컬에서 Migration이 성공적으로 끝나며, Deployment 패키지를 Azure ToolKit을 이용하여 생성하면 되는데, 여기서 하나의 문제점이 생겼다.

아래의 스크린샷에 보이는 것처럼, PowerShell에서 패키지를 생성하는 도중 "The file is too long. This operation is currently limited to supporting files less than 2 gigabytes in size." 라는 오류가 발생하였다. 



Sitecore의 Flash Installtion의 사이즈가 얼마나 될지는 모르겠지만, Migration되어진 데이터는 족히 6GB는 넘는것으로 보인다. 몇일동안의 리서치와 테스팅 결과 솔루션이 찾지 못하였고, Siteocre Support Ticket을 만들어 Auzre ToolKit 이슈에 대하여 보고하였다.

몇일후, 사이트코어로 부터 답변을 받았고 이 이슈는 ToolKit의 오류로 확인되었으며, 사이코어에서 문제를 해결하고 있다고한다. 그리고 그 대안의 방법으로 SQL Server Management Studio을 사용하여 Sitecore의 Azure Database를 컨넥하고 Database를 Migration한다. Configuration 및 Assemblies 파일들은 수동의 옮겨야한다.

  1. Using Sitecore Azure Marketplace, deploy a clean solution to Azure: https://azuremarketplace.microsoft.com/en-us/marketplace/apps/Microsoft.AppSvc_SiteCore_IFrame
  2. Using FTP access, copy custom file-based content to your solution
  3. In the Azure SQL Server firewall, allow access for your IP address, via Azure Portal
  4. Connect to Azure SQL databases using the SQL Server Management Studio and restore your databases on top of clean ones As a result, you should get a customized solution (with all your files) that contains the custom content (your databases).

모든 과정이 끝나면, 반드시 Sitecore.config 파일에서 Temp Folder 경로가 제대로 설정되어있는지 확인 후, "Rebuild Indexes" 와 "Rebuild Link Databases" 작업을 사이트코어 Control Panel에서 수행하여야 한다.




2017년 12월 6일 수요일

사이트코어 개발자 시험버전 다운로드하기

최근 사이트코어는 XP를 처음 사용해보는 개발자들에게 60일 무료 시험버전을 제공하기 시작했다. 아래의 사이트에서 등록을 하면, 사이트코어는 60일 제한 라이센트를 제공하며, 개발자는 그 기간내에 어떻게 플랫폼의 API 및 Helix 프레임워크 사용과 플랫폼 확장 개발등을 할수가 있다. 만약 60일 기간이 만료가 되었다면, 한번 더 연장이 가능하므로 최대 120일까지 사용할수가 있다.

*혹시, 설치 및 사용에 대하여 궁금한점이 있다면 오른쪽의 메일 보내기를 통하여 글쓴이에게 연락하여 주십시오.




===================== 업데이트 =====================

최근 사이트코어는 이전에 공개하였던 개발자버전의 시험 라이센스 중단하였다. 개발자 라이센스는 사이트코어의 프리뷰 버전으로 공개하였던것으로, 2018년도에 새로운 라이센스버전을 공개할 예정이다. Waiting List에 등록을 해놓는다면 조금 더 빨리(?) 라이센스를 받고 테스트할수있는 기회가 주어진다.





2017년 11월 20일 월요일

Sitecore 9.0 Dynamic Placeholder 사용법

사이트코어는 9.0을 릴리즈하면서, DynamicPlaceholder라는 새로운 SitecoreHelper를 소개하였다.

기존의 @Html.Sitecore().Placeholder("key")와는 달리, @Html.Sitecore().DynamicPlaceholder("Key", optional parameters)는 새로운 Placehoder를 좀 더 효율적으로 생성 및 관리할수 있으며, Placeholder Key이름에 렌더링 아이템 아이디와 인덱스를 추가하여 똑같은 Placeholder key를 중보긍로 사용할수 있도록 하였다.

예: placeholderName-RenderingID-Count
content-{4C770DD9-F840-45AB-A22F-8CCAAC42F646}-0

먼저, 아래는 DynamicPlaceholder Method에서 사용가능 한 Parameter의 목록을 나열하였고, 각각 어떻게 사용되어지는지 알아보도록 하자.


DynamicPlaceholder(string placeholderName, int count = 1, int maxCount = 0, int seed = 0)
DynamicPlaceholder(string placeholderName, TagBuilder chrome, int count = 1, int maxCount = 0, int seed = 0)
DynamicPlaceholder(string placeholderName, Func<DynamicPlaceholderRenderContext, TagBuilder> chromeResolver, int count = 1, int maxCount = 0, int seed = 0)
DynamicPlaceholder(string placeholderName, Func<HtmlString, HtmlString> outputModifier, int count = 1, int maxCount = 0, int seed = 0)
DynamicPlaceholder(DynamicPlaceholderDefinition definition)


  1. DynamicPlaceholder(string placeholderName, int count = 1, int maxCount = 0, int seed = 0)

    기본 Placeholder Method처럼 @Html.Sitecore().DynamicPlaceholder("placeholder name") 처럼 사용할 수 있지만, 추가적으로 기본 선택적인 Parameter인 count, maxCount, 그리고 seed를 사용함으로써 해달 Placeholder를 제한적으로 사용할 수가 있다.

    @Html.Sitecore().DynamicPlaceholder("content", count:2)
    

    - count: 사용하고 싶은 Placeholder 수를 정함.
    - maxCount: 맥시멈 Placeholder 수를 정함. 예를들어, count가 "5"이고 maxCount를 "3"으로 정했다면, 페이지에서는 maxCount인 3개의 Placeholder만 나타남.
    - seed: Placeholder의 카운티은 "0"에서 시작되며, 특정하게 시작하는 수는 정하고 싶다면 seed를 사용하면 됨


  2. DynamicPlaceholder(string placeholderName, TagBuilder chrome, int count = 1, int maxCount = 0, int seed = 0)

    첫번째, 메소드의 형식과 달리 이번 메소드는 TagBuilder 오브젝트를 패스하여 새로운 HTML 마크업을 생성할수가 있다.

    @{
        TagBuilder newTag = new TagBuilder("div");
    
        newTag.GenerateId("unique-id-here");
        newTag.AddCssClass("custom-class-name-here anotheer-class-here");
        newTag.InnerHtml = "This DIV is built by TagBuilder";
    }
    
    @Html.Sitecore().DynamicPlaceholder("content", newTag, count: 2, seed: 5)
    
    // 또는,
    
    @Html.Sitecore().DynamicPlaceholder("content", 
                                        output =>
                                        {
                                            newTag = new TagBuilder("Div");
                                            newTag.GenerateId("unique-id-here");
                                            newTag.AddCssClass("custom-class-name-here another-class-here");
                                            return newTag;
                                        }, 
                                        count: 2,
                                        seed: 5)
    

    위의 예제처럼, 새로운 태크 생성을 위한 Argument를 메소드에 전달하였으며 seed를 "5"로 세팅함으로써 Placeholder 카운터가 "5"부터 시작한다.

    HTML Preview Output 
    <div class="custom-class-name-here another-class-here" id="unique-id-here"></div>
    <div class="custom-class-name-here another-class-here" id="unique-id-here"></div>
    

  3. DynamicPlaceholder(string placeholderName, Func<DynamicPlaceholderRenderContext, TagBuilder> chromeResolver, int count = 1, int maxCount = 0, int seed = 0)

    두번째 예제에서의 문제점은 똑같은 HTML 마크업을 생성할수는 있으나, 마크업의 Attribute (클래스 이름 또는 아이디 이름)등을 Unique하게 생성할수가 없다. 똑같은 클래스 이름이나 아이디를 사용하면 Javascript 이벤트를 불러오는데어서 Conflict 문제가 생길수가 있다. 사이트코어 Presentation 네임스페이스의 DynamicPlaceholderRenderContext 클래스를 사용하여, Placeholder의 속성값을 가져올수가 있다.

    // @View
    <div class="row">
        @functions
        {
            TagBuilder CreateColumn(DynamicPlaceholderRenderContext context)
            {
                var col = new TagBuilder("div");
                col.GenerateId("column-id-" + context.Index);
                col.AddCssClass("col-lg-" + 12/context.PlaceholdersCount));
                return col;
            }
        }
        @Html.Sitecore().DynamicPlaceholder("content", CreateColumn, count: 3, seed: 20, maxCount: 4)
    </div>
    

    위의 예제는 context.PlaceholderCount을 Argument에 세팅한 Count의 값 "3"의 불러와 새로 생성되는 "<div>" 마크업의 클래스이름 "col-lg-{count}"으로 정하도록 하였다. 또한, Unique한 ID를 생성하여 context.Index값을 차려로 나열하도록 만들었다.



    HTML Preview Output
    <div class="row">
        <div class="col-lg-4" id="column-id-0"></div>
        <div class="col-lg-4" id="column-id-1"></div>
        <div class="col-lg-4" id="column-id-2"></div>
    </div>
    

  4. DynamicPlaceholder(string placeholderName, Func<HtmlString, HtmlString> outputModifier, int count = 1, int maxCount = 0, int seed = 0)

    이번에도 3번째 예제와 비슷하게 Placeholder 속성값을 전달하여 새로운 HTML 마크업 또는 값을 생성하여, 원하고자하는 Placeholder의 마크업을 생성할수있다.

    @Html.Sitecore().DynamicPlaceholder("content", 
                                        (input, context) => new HtmlString(String.Format("<div class=\"custom-class-{1}\">{0}</div>", 
                                                            input, 
                                                            context.DynamicKey)
                                        ), 
                                        count: 50,
                                        maxCount: 3, 
                                        seed: 50)
    

    이번 예제에서는 해당 Placeholder의 DynamicKey의 값을 사용하였고, 값은 PlaceholderName-UniqueRenderingID-Count 값으로 HTML 마크업에 나타난다.

    <div class="custom-class-content-{4C770DD9-F840-45AB-A22F-8CCAAC42F646}-50"></div>
    <div class="custom-class-content-{4C770DD9-F840-45AB-A22F-8CCAAC42F646}-51"></div>
    <div class="custom-class-content-{4C770DD9-F840-45AB-A22F-8CCAAC42F646}-52"></div>
    

  5. DynamicPlaceholder(DynamicPlaceholderDefinition definition)

    마지막으로 DynamicPlaceholderDefinition 오브젝트는 지금까지 설명한 모든 옵션을 통합한 클래스이다. 새로운 오브젝트에 Placeholder 이름을 정하고, 필요한 인덱스값을 정해주며, Placeholder의 속성값을 HTML 마크업의 Unique한 값으로 정할수가 있다.

    @Html.Sitecore().DynamicPlaceholder(new DynamicPlaceholderDefinition("content")
    {
        Count = 5,
        MaxCount = 10,
        Seed = 100,
        OutputModifier = (input, context) => new HtmlString(String.Format("<div class=\"definition-{1}\">{0}</div>", input, context.Index))
    })
    


    <div class="definition-0">content-{4C770DD9-F840-45AB-A22F-8CCAAC42F646}-100</div>
    <div class="definition-1">content-{4C770DD9-F840-45AB-A22F-8CCAAC42F646}-101</div>
    <div class="definition-2">content-{4C770DD9-F840-45AB-A22F-8CCAAC42F646}-102</div>
    <div class="definition-3">content-{4C770DD9-F840-45AB-A22F-8CCAAC42F646}-103</div>
    <div class="definition-4">content-{4C770DD9-F840-45AB-A22F-8CCAAC42F646}-104</div>
    


2017년 11월 7일 화요일

Sitecore 9 Forms의 새로운 기능

이전 포스트에 소개한것처럼, 사이트코어 9 에서는 Forms 라는 모듈이 소개되었다.

기존에 사용하던 WFFM (Web Forms For Marketers)를 대체하는 모듈로써, WFFM보다 더 진보(?) 되어진 모듈이라고 할수있으며, Forms는 Web Form이 아닌 MVC 기반으로 만들어져 새로운 UI/UX를 통하여 Non-Technical 유저에게도 사용하기 편하도록 만들어졌다.

기본적으로 HTML Element를 쉽게 추가하고 목록을 변경할수 있도록 Drag & Drop 기능이 소개되었으며, 아래는 Forms 모듈의 기능을 나열하였다.


  • 웹사이트 Visitor들의 폼 페이지를 렌더링 수
  • 필드 검증절차를 통하여, 오류 빈도 및 소요한 시간 분석
  • 멀티 페이지 (예, 페이지1 -> 다음 -> 페이지2 -> 다음 -> 페이지 3 -> 등록) 등록 가능
  • Submit 버턴을 통하여 마케팅 캠페인과 호환
  • Javascript 및 CSS 등 추가 리소스 등록가능
  • CSS Class 필드를 통하여, 새로운 스타일 생성가능
  • Forms 템플릿을 생성하여 많은 페이지를 쉽게 생성할수있음
  • Ajax를 이용하여 페이지 로딩없이 페이지를 이동할수있음
  • 필요에 따라 추가적인 필드 검증과 액션버튼 이벤트 생성 가능

사이트코어 - Sitecore 9 Forms Tab

사이트코어 - Sitecore 9 Forms



* 사이트코어는 9.0까지 WFFM를 지원하지만, 버전 9.1부터는 WFFM Support를 중단할 예정이다.



2017년 10월 26일 목요일

Sitecore 9.0 새로운 기능 및 기술

저번 주에 라스베가스에서 열린 Sitecore Symposium 2017을 무사히 마치고 돌아왔며, 이번 Symposium에서 사이트코어는 Sitecore Experience Cloud 9.0 릴리즈 하였다.

개인적으로 이번 토론회는 처음 참석하는 것이므로 무엇보다 기대가 많았다. Sitecore MVP로써 Sitecore 9.0을 미리 시험할수 있었으며, MVP들의 피드백을 토대로 사이트코어는 새로운 SIF (Sitecore Installation Framework) 보완하는 계기도 되었다.

아래는 이번 Sitecore 9.0 에서 적용되는 새로운 중요 기술 및 기능들이며, 차후 각각 기술에 대한 상세한 설명을 포스트 할 예정이다.

xConnect

사이트코어 XP와 xDB 사이에 존재하는 새로운 Service Layer로써, xConnect는 사이트코어가 아닌 다른 플랫폼 및 디바이스와 연동 할수가 있다. xConnect는 Collection과 Search 서비스로 구성되어 있으며, 다른 플랫폼과 디바이스는 xConnect를 통하여 사이트코어 xDB의 데이타를 불러올 수 있으며, 또한 xConnect는 다른 플랫폼의 데이타를 xDB를 가져올수가 있다.

SQL Server

Sitecore 7.5부터 적용해오던 MongoDB 를 필수요소에서 제외하였다. SQL Server를 기본 Provider로 설정되어졌으며, MongoDB 는 선택적인 항목이 되었다. 사용자 및 개발자 환경에 따라 SQL Server, SQL Azure, CosmosDB, 또는 MongoDB를 사용할수있으며, 어떤 DB 타입 상관없이 xConnect는 이 모든 데이타베이스 서버와의 호환되며 작동한다.


Forms

사이트코어 8.2까지 WFFM (Web Form For Marketers) 모듈을 사용하여, 온라인 폼 페이지를 만들고, xMarketing과 컨넥하여 사용자 및 유저의 정보를 모아왔으나, 9.0부터는 새로운 Form 빌더를 Sitecore XP (Experience Platform)에 추가였으며, UI/UX 역시 더 세련(?)되어 만들어졌다.. 이로써, 새로운 폼 모듈을 추가적으로 설치 하지 않아도 된다. Sitecore 9.0까지는 계속 WFFM을 지원하고 서포트를 하지만, 9.1부터는 WFFM 모듈 및 서포트를 중단할 계획인다.

Marketing Automation

기존에 사용해오던, Engagement Plan를 보완한 기능이며, Drag/Drop을 통하여 쉽게 마케팅 로직을 생성할수있다. 손 쉬운 UI/UX 바탕으로 마케터는 쉽게 자동화된 마케팅 캠페인을 생성할 수 있다.

Search

Sitecore 8.2까지 기본 서치엔진이던 Lucene 사용을 중단하고, 기본 엔진으로 Solr 또는 Azure Search를 사용한다. Lucene를 파일을 기반으로한 서치엔진으로 모든 데이타가 파일형식으로 저장되는것으로 반해, Solr 은 웹어플리케이션으로써 Lucene 을 탑재하여 다양한 API를 제공하며, 서치엔진은 사용 용도에 맞게 구현할수가 있다. 
Sitecore 9.0는 OWIN authentication 미드웨어를 통하여 새로운 로그인 방식을 구현한다. 기존의 LDAP 모듈을 이용하여 Active Directory의 데이터를 Sitecore CMS와 통합하여 로그인을 구현하였지만, 이번 Federated Authentication을 사용함으로써 아래의 다양한 플랫폼과 연동시킬수 있다. 예를 들면, Sitecore의 로그인을 Azure AD와 통합을 할수가 있다.
  • OpenId Connect (AzureAD, identity server) 
  • Microsoft Account 
  • Google
  • Facebook 
  • Twitter 
  • WS-Trust (Web Services Trust Language)
  • OAuth 
  • SAML


Dynamic Placeholder

이전부터 많이 문제가 제기되어왔던 기존 Placeholder에 대한 기능은 많이 제약이 따랐다. 예를 들어 렌더링 아이템에는 같은 이름의 Placeholder를 사용하지 못하였으며, 이로인하여 각각 새로운 Placeholder Setting을 적용해야만 했다. 하지만, 이름처럼 이를 다이나믹하게 보안하여 하나의 Placeholder Setting 아이템을 다양하게 구현하도록 만들었다. 차후, 여기에 대한 자세한 설명을 포스트하도록 하겠다.





2017년 10월 4일 수요일

사이트코어 필드 아이템 Versioned, Unversioned 그리고 Shared 속성 적용하기

이번에는 사이트코어의 기본기능에 대하여 소개해보도록 하겠다.

모든 페이지 아이템은 탬플릿에 의하여 생성되며, 탬플릿을 생성할시 유저는 필드 이름과 필드 타입을 설정하여야 한다. 탬플릿을 생성하고 필드를 추가하면 해당 필드의 설정에 Unversioned 와 Shared라는 체크박스가 있다.



필드를 새로 성성하면, 자동적으로 두 체크박스를 선택되어지지 않으므로써 Versioned라는 세팅으로 필드를 생성한다.

먼저, 페이지 아이템에 2개의 언어가 설정되어있고, 각각 2개 및 3개의 페이지 아이템 버전이 있다고 생각하자.
필드 이름: "Test", 필드 기본값: "Test Version"
    • PageItem 버전1 : 영어
    • PageItem 버전2 : 영어
    • PageItem 버전3 : 영어
    • PageItem 버전1 : 일본어
    • PageItem 버전2 : 일본어


아래는 각각 설정이 어떻게 적용되어지는 알수가 있다.

  • Unversioned (적용 안함), Shared (적용 안함)
    필드에 새로운 값이 적용되면, 오직 해당 아이템 버전과 해당 언어에만 새로운 값이 적용된다. 예를 들어, "PageItem 버전 2: 영어" 아이템의 "Test" 필드 값을 "Test Version 2"로 설정할시,
    • PageItem 버전1 : 영어 - 필드값: "Test Version"
    • PageItem 버전2 : 영어 - 필드값: "Test Version 2"
    • PageItem 버전3 : 영어 - 필드값: "Test Version"
    • PageItem 버전1 : 일본어 - 필드값: "Test Version"
    • PageItem 버전2 : 일본어 - 필드값: "Test Version"

  • Unversioned (적용), Shared (적용 안함)
    필드에 새로운 값이 적용되면, 오직 해당 언어의 모든 아이템 버전에 새로운 값이 적용된다. 예를 들어, "PageItem 버전 2: 영어" 아이템의 "Test" 필드 값을 "Test Version 2"로 설정할시,
    • PageItem 버전1 : 영어 - 필드값: "Test Version 2"
    • PageItem 버전2 : 영어 - 필드값: "Test Version 2"
    • PageItem 버전3 : 영어 - 필드값: "Test Version 2"
    • PageItem 버전1 : 일본어 - 필드값: "Test Version"
    • PageItem 버전2 : 일본어 - 필드값: "Test Version"

  • Unversioned (적용 안함), Shared (적용)

    필드에 새로운 값이 적용되면, 모든 언어의 모든 아이템 버전에 새로운 값이 적용된다. 예를 들어, "PageItem 버전 2: 영어" 아이템의 "Test" 필드 값을 "Test Version 2"로 설정할시,
    • PageItem 버전1 : 영어 - 필드값: "Test Version 2"
    • PageItem 버전2 : 영어 - 필드값: "Test Version 2"
    • PageItem 버전3 : 영어 - 필드값: "Test Version 2"
    • PageItem 버전1 : 일본어 - 필드값: "Test Version 2"
    • PageItem 버전2 : 일본어 - 필드값: "Test Version 2"