検証環境は次の通りです。 Sitecore Experience Platform 8.2 rev. 161221 (8.2 Update-2) Jenkins 2.53     概要: 継続的インテグレーション（CI）を使用することで、アプリケーションに定期的な拡張機能やバグ修正を簡単かつ迅速かつ安全に行うことができます。 今回はJenkinsとGitHub を使ったセットアップのメモ書きです。   始まり: 現在のお客さんで、毎日朝、開発者が手動でコードマージをし、ビルドしてから、環境別にデプロイを行っています。これをJenkinsとGitHub使って自動に行うということです。 Jenkins自体のインストールをここにて省略します。   要求されたのは： １．developブランチからqaブランチへのコードマージ ２．コードマージ後ビルドします。 ３．失敗する場合はアドメインや開発者がへメールにて連絡します。 ４．成功する場合はQAサーバへコードデプロイします。 ５．QAサーバへコードデプロイ完了後、Repoへマージしたコードをプッシュします。 ６．アドメインと開発者にてデプロ完了をメールにて連絡します。   図を描くと、こんな感じですかね。。。   セットアップ手順 １．General： まず、新規にJenkinsのタスクを作成します。 ２．Source Code Management: このセクションにてレポジトリのURL,ログインを設定します。 ”Additional Behaviours”にて、developブランチからqaブランチへのコードマージを設定します。 ３．Build Triggers: ビルドをいつ走らせるのを設定します。例えば、月曜日から金曜日の朝8時半に毎日ビルドをするには： [infobox icon=”arrows”]＊フォーマット： MINUTE (0-59), HOUR (0-23), DAY (1-31), MONTH (1-12), DAY […]

検証環境は次の通りです。 Sitecore Experience Platform 8.2 rev. 161221 (8.2 Update-2)   概要: お客さんから、エンドユーザーより、一度PDFを開いたら、新しいPDFが更新されてでも、ブラウザのキャッシュクリアしない限り更新されれないといわれました。これはPDFのブラウザのキャッシュクリアをする手順のメモ書きです。   試みその一、max-age このKBの記事によりますと、既にパブリッシュされたメディアアイテムに新しいコンテンツが添付され、メディアアイテムが再度パブリッシュされると、そのURLを使用してメディアにアクセスすると、直ちにコンテンツ変更がブラウザに反映されないことがあります。これは、MediaResponse.MaxAge設定で指定された時間、メディアがブラウザにキャッシュされているために発生します。ブラウザがメディアアイテムを既に使用している場合、サーバーへのリクエストは実行されず、キャッシュからメディアアイテムを取得できます。 キャッシュされたバージョンの有効期限が切れます。しかし、これはすべてのメディアアイテム応用され、PDFだけに応用することができなかった。   試みその二、ユニークなパラメータ MediaProviderを変更し、メディアアイテムURLにユニークなパラメータを追加することでザのキャッシュクリアします。この場合はPDFのURLだけにユニークなパラメータを追加することができます。これはいけるぞ思った。しかし、メディアアイテムURLの生成はViewに限らず、下記のところで、その変更に必要以上な変更が必要と分かった。  例えば、このメディアアイテムURLがリッチテキストエディタにて追加された場合は、 <a href=”/-/media/test/files/feature-articles/client_feature_next_2018.pdf? la=en” target=”_blank” data-ga-category=”Download: PDF?LA=EN” data-ga- action=”Download” data-ga-label=”https://www.test.com/-/media/test/files/feature- articlesclient_feature_next_2018.pdf?la=en”>View a PDF of this feature article</a> また、Coveoを使用したサーチ結果のリストにあるURLがCoveoより生成され、Coveoのモジュールの変更が必要とされてしまします。ですので、これで対応できなかった。   試みその三、メディアハンドラーsitecore_media.ashx このハンドラはすべての/ – / media / …リクエストをキャッチし、最終的にメディアプロバイダを呼び出しています。つまり、サイトにてすべてのメディアのリクエストを処理するさいに、PDFである際にブラウザのキャッシュクリアをすればいいです。これは既存のメディアURLの変更をする必要がなくなります。一番簡単な変更であった。   さて、コードを見て目ましょう。 1．好きなツールを使って、DLLのコードを開きます。 　　　 2．MediaRequestHandlerをソリューションへコピーし、SendMediaHeadersの処理の最後にPDFである場合はブラウザのキャッシュクリアします。 　　　 ３．web.configにてMediaRequestHandlerを切り替えます。 　　　 環境別のTransformationの場合は下記のように設定すればいい。 <add […]

検証環境は次の通りです。 Sitecore Experience Platform 8.2 rev. 161221 (8.2 Update-2)   概要: お客さんから、WebデータベースのサイズがMasterよりも多きといわれ、現在使用しているサイトコアのバージョンにてBlobsテーブルのクリーンアップがされていないことが分かった。どうも、バージョン8.2以降、この問題が解決されていま。 もし、同じサイトコアのバージョンで同じ問題があった場合はこれはBlobsテーブルのクリーンアップのメモ書きです。 まず、データベースのサイズを確認しましょう。下記のクエストをMasterとWebにて走らせて、結果を比較すればいい。 SELECT o.name AS table_name, sum(p.reserved_page_count) * 8.0 / 1024/1024 AS size_in_gb, p.row_count AS records FROM sys.dm_db_partition_stats AS p, sys.objects AS o WHERE p.object_id = o.object_id AND o.is_ms_shipped = 0 GROUP BY o.name, p.row_count ORDER BY size_in_gb DESC 御覧のように、Webデータベースのほうが断然大きい… クリーンアップのクエスト下記の通りです。必要なレコードの数を変更しWebにて走らせばいい。 Delete from blobs where blobid […]

検証環境は次の通りです。 Sitecore Experience Platform 8.2 rev. 161221 (8.2 Update-2)   概要: タイトルのようにサイトコアのアドメインページにて、ジョブビューアのページがあります。 ジョブビューアにて、現在実行中のジョブ、実行待ちのジョブまたは最近実行されたジョブのリストが表示されます。 このページが非常に便利で、私はどのようなの時にこれを使うのかを書いてみたいと思います。 パブリッシングのステータス よくお客さんに聞かれる質問で、パブリッシングする際にパブリッシング待ち状態となったり、サイトコアからログアウトされたり、そうなった場合はパブリッシングの状態が分からなくなります。その際にパブリッシングの進行状態を聞かれることがよくありませんか？ この際にジョブビューアにて一目瞭然です。パブリッシング待ちとなった際にジョブビューアにて確認をしましょう： インディクスの再構築のステータス 同じく、インディクスの再構築の際サイトコアからログアウトされ、インディクスの再構築の状態が分からなくなった際に、 ジョブビューアにて進行状態の確認ができます。 特に多数のインディクスの場合はこれが便利です。 サイトパフォーマンストラブルシューティング お客さんから、サイトのレスポンスタイムが遅くなったよと言われた際に、ジョブビューアにて待ちしているジョブがあるかどうかを手軽く確認することができます。また、EventQueue Statisticsページを合わせて、サイトパフォーマンストラブルシューティング最初のステップとして使えます。これらの状態が正常出れば、ログファイルにてもっと詳細を見ていきます。

概要:Coveo Admin Overview ページにおいて、最後のソースの更新/再構築のステータスが更新されないについてのメモ書きです。 検証環境は次の通りです。 Cover Version 4.0 Coveo for sitecore 81 4.0(895) Coveo Enterprise Search 7.0 x64(8691) for Sitecore Coveo Search API 8.0.1130 最近の作業でお客さんから、Coveoの管理者にログオンして、「最後のソースの更新/再構築は更新されません」にて、最新のインデックス再構築時間が正しくないといわれました。実際にインディクスをサイトコアにて再構築をすると、確かに「最後のソースの更新/再構築は更新されません」にて正しく更新されていなかった。 その上、お客さんがCoveo Adminにてインデックス再構築すると、四秒間で完了しました。これはサイトコアで同じインデックス再構築するには二時間以上かかることに対して、あまりにも短い過ぎます。 Coveoインデックス再構築に関する記事によりますと、インデックス再構築はサイトコアでで行うことを書かれており、CoveonのAdminにて行う関連記事が見つかりませんでした。 また、この記事によりますと、CESにてインデックス再構築のステータスもモニターすることができます。 確認として、サイトコアでにてインデックス再構築を始め、ローカルのCESコンソールにてステータスの確認ができました。また、サイトコアインデックス再構築の結果ウィンドウにて正常にインデックス再構築完了することができたものの、CoveonのAdminにてステータスが更新されていなかった。 Coveo のサポートと連絡を取ったところ、これは正しい動作であるといわれました。Coveoのサポートによると、Sitecoreがプッシュソースであるため、 初期ビルド後に”Last Source Refresh / Rebuild”のステータスが更新がされません。CESはSitecoreからドキュメントをフェッチできません。キュー内で待機しているドキュメントのみを処理できます。”Live Monitoring”が有効になっているので、CESはキューを処理するためにキューに追加されるアイテムを常に待っています。それらを処理するとき、それは「再構築」としては見られず、このフィールドを更新しません。 “Last Source Refresh / Rebuild”の状態を更新するには、”Live Monitoring”をまず無効し、それから、手動またはスケジュールどおりに再構築/更新を開始する必要があります。これによって、リフレッシュ/リビルドフィールドで、キュー内のアイテムは単独で処理され、”Last Source Refresh / Rebuild”の状態を更新されます。 “Live Monitoring”を無効にし、手動でサイトコアでにてインデックス再構築し、Coveo Adminにてインデックスの更新をした後、”Last Source Refresh / Rebuild”のステータスの更新時間が正しく反映されました。 […]

概要:Solr Adminでインデックスを確認する手順のクリックメモです。 ————————————————————————————————– 以前、[Sitecore 8][Luke][Lucence]Lukeを使ってサイトコア８のLucenceインデックスの内容を確認するのメモ書きを書いていました。最近のプロジェクトでSolrを使用する場合が出てきたので、その際にインデックスの値を確認したり手順を簡単にまとめていました。Solrのセットアップに関する記事はネットでたくさんあるので、ここで省略します。サイトコアのドキュメントにも詳細な手順が書かれています。 既存のフィールドを確認する   １．まず、Solrのアドメイページへ行きます。 http://localhost:8983/solr/#/   ２．確認したいコアーを選択します。    ３．次にQueryにて検索をかけます。   ４．初めてこれを使う時思ったので、これは簡単だね、でも、 どのフィールドが検索可能なのかはさっぱり。どこを見ればいいのかなぁ。。。 データーベースのSchemaを見れば分かるのではと思って、Schemaをみれば、 フィールドの一覧が表示された。   ５．フィールドを選択するともっと詳細な情報が表示されます。   ６．Queryへ戻り、検索をかけると、結果が表示されます。   ７．予想している結果がなかった場合は、セカンダリを見る際にこれが便利。 ページにて表示されているurlをクリックすると、Jsonフォーマットの結果が表示され、その際に urlにセカンダリのインディクスに切り替えればいいです。   ８．guidで検索する際に、｛｝とーがなく、小文字で検索   例えば、下記のイベントのタイプを検索したいの場合   そのままGUIDを使うと、エラーが表示され、   検索の結果からみれば、GUIDが｛｝とーがなく小文字ですので、   ｛｝、－を削除に、小文字で検索すると結果が出ました。 以上です。

概要: クティブディレクトリモジュールのセットアップ中に見かけるトラブルシューティングのメモ書き ——————————————————————————————— 検証環境は次の通りです。 Sitecore Experience Platform 8.2 rev. 161221 (8.2 Update-2) Sitecore Active Directory component 1.3 rev.161017   毎日仕事が忙しくてなかなかちゃんとしたブログを書く時間がなくていらいらしております。 今回、サイトコアのアクティブディレクトリモジュールのセットアップについては、下記のようにネッとって多くのブログがあります。以前のバージョンのサイトコアのアクティブディレクトリモジュールも何回かセットアップしたことがあり、ログインさえ正しいであれば、簡単に接続ができます。今回のセットアップでちょっと手間がかかり、ブログ・メモ書きとして、もっと設置を深く、問題が発生する際にどのような手順でトラブルシューティングするのを書いています。 まず、サイトコアのアクティブディレクトリモジュールのセットアップについてネットでたくさんの記事が書かれています。 https://sitecorecommerce.wordpress.com/2017/07/31/sitecore-active-directory-module-1-3-setup-guide/ http://blog.peplau.com.br/en_US/best-way-to-setup-active-directory-module-in-a-sitecore-solution/ https://www.linkedin.com/pulse/sitecore-82-active-directory-13-integration-mohd-naeem また、アクティブディレクトリモジュールのセットアップガイドも詳細に書かれいます。 https://dev.sitecore.net/Downloads/Active_Directory/1_3/Active_Directory_1_3.aspx# 基本的にアクティブディレクトリモジュールをインストール後、下記の設定を行います。 私はサイトコアhabitatベースのソリューション使っているので、transformファイルを追加また、 修正し、gulpタスクをはしらせばいいです。 GITHUBへ追加してそしてリンクする Sitecore.config.transform <?xml version=”1.0″?> <sitecore database=”SqlServer” xmlns:xdt=”http://schemas.microsoft.com/XML-Document-Transform”> <!– SWITCHING PROVIDERS –> <switchingProviders> <membership> <provider providerName=”ad” xdt:Locator=”Match(providerName)” xdt:Transform=”InsertIfMissing” storeFullNames=”false” wildcard=”*” domains=”ad” /> </membership> <roleManager> <provider providerName=”ad” […]

概要:GitKrakenを使ってみるノードです。   これまでにTortoiseGitをメインで使ってきました。クライアントによって、いくつかのバージョン管理ツールを使ってきましたが、GUIでもっとも使ってきたのはSourceTreeでした。今回の開発チームでGitKrakenを使う開発者がいたので、それに合わせてGitKrakenに切り替えました。切り替えの際に思ったことのメモ書きです。 セットアップ   インストールから最初のClone迄の設定はシンプルで画面自体大きくととてもモダンなデザインって感じです。アカウントの情報を設定し、   リモートリポジトリからCloneするのも簡単。よく使われているGitサービスの会社がリストされいるので設定されているプロファイルでログインが簡単。 SourceTreeと比べて、インストールが早く、ソースコードが複数のサービスプロバイダーで管理されている際に、GitKrakenのセットアップが断然使いやすい。 とまとったこと   ■ローカルにCloneしたリポジトリを削除 作業を終え、必要がなくなったローカルにCloneしたリポジトリを削除する際に、 SourceTree　また　TortoiseGitのようにフォルダで右クリックで削除することができなかった。   ファイルの名前を変更するか、リポジトリの設定ファイルにて手動で削除する必要があります。   ■SourceTree　で使い慣れていた機能の一つはファイルの場所です。右クリックで、すぐにファイルをエクスプローラーにて開くのを慣れていました。   しかし、GitKrakenにてこの選択がなく、ちょっととまとってしまいました。   しかし、右側のパネルにて、ツリービューでした場合はファイルエクスプローラーと同じピューができ、その上、右クリックにて、エクスプローラーでファイルを開きます。個人的にこちのほうが好みます。 その他の機能   ネットでGitKrakenの使い方の掲示が沢山あり、ここでいちいち書きません。 Axosoftの下記のブログをぜひ目を通して見てください。英語ですが、アニメーションでステップを教えているので、アニメーションで理解ができます。 https://blog.axosoft.com/2016/11/09/gitkraken-tips-3/ https://blog.axosoft.com/2017/05/17/gitkraken-tips-5/ https://blog.axosoft.com/2016/06/28/gitkraken-tips/ https://blog.axosoft.com/2016/08/17/gitkraken-tips-2/ 思ったこと   GitKrakenに切り替えたとはいえ、やはり、TortoiseGitを手ば去られない。 例えば、TortoiseGitでソフトを立ち上がらず、右クリックでどこでもCloneができるのはやはり便利   まな、日々の作業でよくエクスプローラーにてソリューションファイルを開きます。 よく月曜ににどのブランチで作業しているのを知りたい時はソフトを立ち上がらず、 右クリックでTortoiseGitにてすぐに確認できることが便利です。

概要:Windowsでの大文字と小文字の区別しないので、違ったファイルパスを早く修正するツールGitUniteのメモ書き きっかけ Windowsでは大文字と小文字が区別されないに対して、gitインデックスの大文字と小文字を区別するので、GitHubのコードリポジトリをブラウズする際、また、Linuxでファイルをチェックアウトした際に違ったファイルパスとして表示されます。 例えば、GitHubのコードリポジトリをブラウズする際に下記のように違ったファイルパスが表示されているに対して、 Windowsにおいて、ファイルパスが正しく表示されているように見えます。 これは共同開発する際にそれぞれの開発者がが最初にフォルダをソリューションへ追加する際に一致した名前の作成がしていないからです。開発をしたがって、このようなの違いが多くなり、ウィブにてGitHubのコードリポジトリをブラウズまで、問題がとして発覚されないのです。 もし、変更するファイルは少ないの場合は直接ウィブのGitHubコードリポジトリにて変更すればいいです。参照：https://github.com/blog/1436-moving-and-renaming-files-on-github これにて、フォルダ名の変更ができます。 しかし、開発の途中でこれを発覚した場合は複数のファイルやフォルダをこのような手動で個別に移動するわけにはいきます。その際にGitUniteというツールを使用すれば簡単に修正ができます。 GitUniteでファイルパスの修正 1．GitUniteをダウンロードします。 ここにてソースコードをチェックアウトします。 ソリューションを開き、ビルドし、exeファイルを生成します。 2．パワーシェルを立ち上げ、ローカルのリポジトリへ移動し、GitUniteを実行。 例： PS C:\localRepo\sandbox> C:\Git.Unite\bin\Debug\Git.Unite.exe C:\localRepo\sandbox 3．実行後、結果を確認します。 PS C:\localRepo\sandbox> git status 変更されたファイル、フォルダのサマリーが表示され、正しいかどうかを確認。 renamed:    feature/navigation/test.txt -> Feature/Navigation/test.txt renamed:    feature/navigation/navigation.c -> Feature/Navigation/navigation.c ４．確認後変更をレポジトリへチェックインし、ウィブにてGitHubのコードリポジトリをブラウズして修正されてことをを確認します。

先週二つのブログでテキスト検索のツールとして、下記の二つのツールについて 書かれた方がいました。   Notepad++  AstroGrep　   私はNotepad++メモ帳の代わりに日々使っております。昔、UNIXの開発をしていた際に grepを使ってきましたが、ウィンドウズに切り替えた際に、PowergrepやAstroGrepを 使っていました。3-4年前に転職時にPowergrepのライセンスがなくなって、無料の検索 ツールを探していた際にSourceForgeはその一つとして使ってみました。   当時思ったのは検索時間がかかるという思いででした。当時行くかのツールを試して後、 Agent Ransackという検索ツールが一番早くて、自分が期待している結果を出している ようで、あれから、ずっとAgent Ransackを使ってきまし。     しかし、もし、ほかの開発者がお勧めであれば、試すべきです。ですので、 AstroGrepをダウンロードしてAgent Ransackと比べてみました。 私は実戦の例を使て検索を比べてみたい。例えば、サイトコアのハビタット（habitat）に既存のニュースモジュールを自分のサイトに導入したい。その際にHabitatのソースフォルダにて、Sitecore.Feature.Newsというキーワードを含むファイルを検索した。その結果をみて、導入する際にファイル漏れがないように確認を取ります。 検索をかけたいソースフォールだにて右クリックでAstroGrepとAgent Ransackを開きます。  まず、AstroGrepを使って試みましょう。すべてのファイルを検索したいので、 Exclusionsにてファイルの拡張選択を外します。   そして、検索を始めましたが、4分近くでエラーで止まりました。。。   さて、Agent Ransackの番で！同じく、すべてのファイルを検索。   あっという間に完了。。。。サマリーを見ると、一秒だけ？   さらに詳細なレポートみると、自分は期待しているファイルリストのようです。   結論として、別の検索ツールが見つかるまで、しばらくAgent Ransackを引き続き使っていきます。