概要: 日々ウィブサイトがAzureへ移行している日々、従来各自のサーバーにて使うお客さんもいます。 サーバーの数によって、デプロイメントする際にウェブサイトをバックアップするのは一般的です。 バックアップに関するツールはたくさんありますが、簡単なバックアップスクリプトをメモ書きとして書きます。 [space size=”10″] きっかけ： デプロイメントをする方がいちいち、ターゲットサーバーへ行き、日付を使ってバックアップのフォルダを作成します。 そして、Websiteフォルダを手動でコピーします。その際に、App_dataとtempフォルダを除きます。 この手順をそれぞれのサーバーで行います。それを見て、PowershellのScriptを書いて、 クリックするだけでやればいいじゃないの聞いたら、スクリプトを書いてくれとといわれた。 [space size=”10″] スクリプト： $src = Read-Host -Prompt ‘ソースパスを入力してください：(ディフォルト：C:\inetpub\wwwroot\Sitecore\Website\)’ $dst = Read-Host -Prompt ‘バックアップされるドライブを入力してください：(ディフォルトは：D:\)’ #ディフォルトのソースパスを設定 if($null -eq $src) { $src = “C:\inetpub\wwwroot\SC9.local\Website\xsl\system\WebEdit”; } #今日の日付を使ってバックアップフォルダを作成 $today = get-date -f yyyy-MM-dd; if($null -eq $dst) { $dst += [string]::Format(“D:\{0}_backup\”,$today); } else { $dst += [string]::Format(“:\{0}_backup\”,$today); } Write-Host “`r`n […]

概要: テンプレートにてリストフィールドがよく使われています。 [space size=”10″] 例えば、製品のカタログなどではれば、リストが何百以上なったりするのは普通です。 開発中またトラブルシューティングにて特定な選択されているアイテムを探すのが場合によって時間がかかります。 今回、案外知られていない簡単かつ早く選択さてているアイテムを特定するここを紹介します。 [space size=”10″] 選択されているアイテムを探すには、よく表示されている選択したアイテム名を使うのが一般的です。 [space size=”10″] ただ、製品のカタログのような、アイテム名が長い場合、また、似たような製品名などを検索をすると、 検索結果一覧がかなりな長くなったり、また検索時間もかかります。 [space size=”20″] 次によく使われている検索方法はGUIDを表示し、GUIDを使って検索し、確実ターゲットを見つけます。 [space size=”20″] ただ、サイトの大きさによって、またネットワークの速度によって、画面切り替えそのものに時間がかかることがよくあります。RAW　Value表示されてから、アイテムテンプレートによって、何百のフィードがある場合、フィードを先に検索しなければなりません。それがまた時間がかかります。 [space size=”20″] ここで案外使われていないテクニックが chrome DevTools です。 検索したいアイテムを選択し、右クリックで、Inspectをすれば、GUIDを素早くコピーすることができます。 [space size=”25″] 簡単なことですけど、これで、画面のリロードやフィード検索を待つ時間を節約することができ、もっと、スムーズに 快く開発ができます。😎

検証環境は次の通りです。 Sitecore Experience Platform 9.0 rev. 180604 (9.0 Update-2) Sitecore PowerShell Extensions 5.0 [space size=”20″] 概要: ローカルの環境にて開発中、時にはデバッグでコードをステップしてい行くことがよくあります。 ただ、もし、コンテンツにあまりにもたくさんのアイテムがある場合はこの作業が時間がかかります。 特に製品のカタログのような、万以上のアイテムがある場合は、たくさんのアイテムをSPEを使って いかに早く削除するメモ書きです。 [space size=”10″] よく使われているのは下記の三つです。 [space size=”10″] １．SQLデーターベースクエリ http://sitecoreexperiences.blogspot.com/2017/11/deleting-sitecore-items-in-sql-proceed.html これは同僚の先輩が書いたクエリです。直接データーベースにてアイテムを削除するので早いです。これは私はプロダクションの環境にて使用することを極めて勧めません。ローカルの環境でディバグの際に便利です。基本的にデータベース内のアイテムデータを直接操作することはお勧めできません。これは走る前にバックアップを取りましょう。また完了後、リンクデータベースの再構築をしましょう。 [space size=”10″] ２．アドメインツールのデーターベースブラウザー http://sc902.local/sitecore/admin/dbbrowser.aspx これは、コンテントエディタトラベルと早です。ただ、同じく直接データーベースにてアイテムを削除するので使用する際に要注意です。同じく、走る前にバックアップを取りましょう。また完了後、リンクデータベースの再構築をしましょう。 [space size=”10″] 3．SPE [space size=”10″] SPEにてアイテムを削除を簡単にできます。使用するコードによって速度も多少違ってきます。 [space size=”10″] テストで２０００のサブアイテムを削除します。91秒かかります。 [space size=”10″] コード：[space size=”10″] Measure-Command { $items = Get-ChildItem -Path “master:/sitecore/content/Home/TestB” -Recurse | Where-Object […]

概要: つい最近、MongoDBサーバーが利用できない場合にSitecore サイトがフリーズしてしてしまったことがあった。 その際に習ったことを共有したいです。[space size=”10″] まず、下記のKB記事にてこれまでに出会った問題がすべてカバーしてきましたが、 MongoDBサーバーが利用できない場合のSitecore XPの動作 https://kb.sitecore.net/articles/930657 特に、この提供されているパッチが一番有効でした。 [space size=”10″] 私が出会ったエラーはサイトがロードし続き何も更新されないもんだだった。 サイトコアのログをみるとと、タイムアウトとあり、てっきり MongoDBサーバーがダウンかと思いました。[space size=”5″] [space size=”10″] MongoDBサーバーをみると特にエラーなどがなく、サービス自体も走っています。[space size=”5″] [space size=”10″] 次にサイトコアのサイトを走っているサーバーのIIS ログを見る限り、サイトがフリーズではなく、リクエストを通常に受け取り、 ただ、タイムアウトされているのでプロセスができていない状態です。[space size=”10″] これだとやはり、MongoDBサーバーに問題があるのではと思い、最後MongoDBサーバーにていろいろとトラブルシューティングを試していました。その際にRoboMongoを使ってローカルのMongoDBサーバーへの接続ができなかった。 パブリックのサイトなのでこれ以上待つことができなかったので、MongoDBサーバーを再起動し、問題を解決しました。 [space size=”10″] さてなんでMongoDBサービスがはしっているので、リクエストをプロセスしないのか、また、なぜ、RoboMongoを 使って接続できないのかがを知りたかった。いろいろと検索したろころで、MongoDB のドキュメントにて https://docs.mongodb.com/manual/core/index-creation/[space size=”10″] [space size=”10″] デフォルトのせていにて、インデックスが実行されている間で、データベースへのすべての操作がブロックされるとありました。 さらに、MongoDBのログをみる、インデックスが実行されていたことが判明。。。[space size=”10″] また、MongoDBが再起動する際にインデックスが環境されていないことも確認を取った。 [space size=”10″] 発生原因を突き詰めたところで解決策としてどうすればいいかサイトコアサポートへ連絡しました。 勧められたのはMongoDB のドキュメントにあるバックグラウンドで実行する設定でした。 [space size=”5″]  xDB Migration Toolにてインデックスをバックグラウンドで実行すれば、MongoDBサービスが通常に動作することを確認しました。[space size=”10″]

検証環境は次の通りです。 Sitecore Experience Platform 9.0 rev. 180604 (9.0 Update-2) Sitecore PowerShell Extensions 5.0 概要: よく、お客さんからいろいろなレポートが要求されるので、Sitecore Fast Queryをメインで使っていました。 一昨年より、SPEに切り替えてから、ずっと、SPEのみ使ってきました。今後よく使った簡単で便利なスクリプト をメモ書きしていこうと思います。　 SPE Sitecore PowerShell Extensions (SPE)  始めとして、Sitecore PowerShell Extensions を使って定期的にレポートをメールで送信するメモ書きをします。 昔、テレビで最大のインフォマーシャルキャッチフレーズを思い出し、　”設定して忘れる ”のように、一度設定すれば、 いちいち確認しなくでも済す。今回、サイトコアのスケジューラーを使って、定期的にレポートを生成し、メールにて送る手順を書き留めます。 1．まず、管理しやすいようにカスタムスクリプトのフォルダを作成します。 　これにて、このサイトに特有な変更であるかどうかを一目瞭然です。     　　 ２．スクリプトを追加します。毎週ごどに送るレポートを設定してみます。 ３．スクリプトのセクションにてウィークリーレポートのスクリプトを設定。 ４．ここにて直接スクリプトを書き、実行することもできますが、PowerShell ISEを使って編集することをお勧めです。 特にディバグとイミディエイトウィンドウの機能をしようすればスクリプトの作成を楽々！！ ５．ウィークリーレポートのスクリプトを　PowerShell ISE　にて作成してみましょう。 まず、簡単なメールを送る関数を作成： function SendEmail { Param( [bool] $UsingGmail, [string] $From, [string] $To, [string] $Subject, [string] […]

概要: つい最近、LuceneからSolrへ切り替えした際にSitecore.ContentSearch.Lucene.DefaultIndexConfiguration.configを無効し、下記のエラーて戸惑い、これはそのメモ書きです。   検証環境は次の通りです。 Sitecore Experience Platform 8.2 rev. 180406 (8.2 Update-7) Cover for Sitecore 4.1.518.18   LuceneからSolrへ切り替えした際,サイトコアが提供されている手順を従い、設定を変更しました。その際に、Sitecore.ContentSearch.Lucene.DefaultIndexConfiguration.configを無効にするとありました。 Walkthrough: Setting up Solr   また、サイトコアのサーバー構成リソースを見る限り、CMとCDサーバーにて Sitecore.ContentSearch.Lucene.DefaultIndexConfiguration.configを無効にする必要があります。   しかし、サイトをロードする際に下記のエラーがでました。   ネットで検索したら、Coveoより、Sitecore.ContentSearch.Lucene.DefaultIndexConfiguration.configを有効にする必要があります。 Coveoの記事:   サイトコアのサポートに確認を取ったところ、これは問題ないとの確認を取りました。　なぜなら、SolrとLuceneは異なるコンフィギュレーションノードを利用していますので、検索プロバイダの競合については何の問題もないはずです。 実際には、必要に応じてLuceneとSolrの両方を同時に有効にすることができます。 変更する必要があるのはインデックスの名前だけなの で、同じ名前のインデックスはありません。なるほどと、一安心。😊

概要: 以前、Sitecore IPジオロケーションサービスを使って、国別にユーザを自動的にリダイレクトするに関する メモ書きを書きました。しかし、Googleのサーチエンジンで用いる検索可能なインデックスを作成するために ウェブ上からドキュメントを収集するGoogleBotを場合を想定していなかった。 今回、簡単にGoogleBotを場外し、また、検証用に使用したツールをメモ書きとしてします。   コードを更新 これは意外と簡単、GoogleBotのようなCrawling　Botsを場外するコードを追加します。 private bool IsCrawlingBots() { var returnVal = false; var CrawlingBots = SandboxSettings.CrawlingBotsExclusions.ToLower().Split(‘,’).ToList(); if (HttpContext.Current != null && HttpContext.Current.Request != null && HttpContext.Current.Request.UserAgent != null) { var uaStr = HttpContext.Current.Request.UserAgent.ToLower(); returnVal = CrawlingBots.Exists(x => uaStr.Contains(x)); } return returnVal; } その後、リダイレクトする前に確認をする。 if (Tracker.Current.Interaction.GeoData.Country != “US” && !IsUserPreferUsSite() && […]

概要: 既存のsolr-6.6.2からsolr-6.6.3へバージョンアップデートのタスクを渡され、 これはその手順のメモ書きです。   三つのステップて行います。 Solr6.6.3へバージョンアップデート Solrウィンドウズサービスの更新 SolrのHTTPSの更新   Solr6.6.3へバージョンアップデート 1 まず、solr-6.6.3をダウンロードし、インストールするところへ解凍する。 この例の場合は：D:\sc9_install\solr-6.6.3 https://archive.apache.org/dist/lucene/solr/6.6.3/solr-6.6.3.zip 2 もし、既存のSolrサービスが走っているなら、それを一時停止します。 3 コンソールにて以前のバージョンのSolrを停止します。 4 コンソールにてSolr 6.6.3をスタートします。 ステータスを確認： ブラウザーにてSolrが走っているのを確認 Solrウィンドウズサービスの更新 1 NSSM – the Non-Sucking Service Manager https://nssm.cc/download　をダウンロード 適度な場所へ解凍。これ例の場合は： D:\nssm-2.24 2 コンソールにてSolrをウィンドウズサービスとして設定： PS D:\sc9_install\nssm-2.24\win64> .\nssm.exe install Solr663 4 Solrサービスが走っていることを確認 5 ブラウザーにて確認： http://localhost:8983/solr/#/   6 ウィンドキー　＋　R　にてレジストリエディタを開き、 Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\　にて 以前のサービスキーを削除します。 SolrのHTTPSの更新 1 手動でsslの設定より、gitlabにてフリーなPowerShellスクリプトあり 使用すると便利です。このスクリプトををjavaのインストール先へダウンロード […]

概要: Sitecore IPジオロケーションサービスを使って、国別にユーザを自動的にリダイレクトする に関するメモ書きです。 もしSitecore IPジオロケーションサービスを使用しているであれば、ユーザの国コードが知ることができますので、それをもとに自動的にリダイレクトします。 国のコードを取得後、リダイレクトするのは簡単ですが、ただ、いくつかの状況を事前考慮しなければなりません。 ■USのユーザが日本へ出張し、現地でUSのサイトへアクセスをすると、ジオロケーションにて日本として判断され、常に日本のサイトへリダイレクトしてしまいます。USのユーザですので日本にいながら、USのサイトへアクセスしたい。 ■USのユーザがVPNや、RDPでUS以外のサーバーへ接続し、サイトへアクセスすると、ジオロケーションが外国と判定し、US以外のサイトへリダイレクしてしまいます。USのユーザですので日本にいながら、USのサイトへアクセスしたい。 ■サイトのサブページへアクセスする際にも国コードをもとにダイレクトされるどうかの判断があり、ユーザーを混乱されないように考慮しなければなりません。 上記の状況を対応するにはなんらかの方法でユーザーにどの国のサイトにてブラウズするという確認を取ることが必要です。よく見かけるのはポップアップウィンドにて、ユーザーが特定の国のサイトにてブラウズするかどうかの確認をとり、 確認を取った時点でクッキーを設定し、ブラウザーが閉じるまで常にこのクッキーを確認し、必要のないリダイレクトを避けます。また、ヘッダーやフッターにある国別のリンクを利用し、クッキーを設定することも見かけます。   例えば、メインのサイトがUSサイトであり、日本のユーザーがUSサイトへアクセスすると、ジオロケーションが日本の国コードが判定され、ユーザを日本のサイトへリダイレクトします。 if (Tracker.Current != null && Tracker.Current.Interaction != null && Tracker.Current.Interaction.GeoData != null && !string.IsNullOrEmpty(Tracker.Current.Interaction.GeoData.Country) && Tracker.Current.Interaction.GeoData.Country == “JP” ) { //日本のサイトへリダイレクトします。 HttpContext.Current.Response.Redirect( HttpContext.Current.Request.Url.AbsoluteUri.Replace( HttpContext.Current.Request.Url.Host, sgWebUrl)); } 一度USのサイトへリダイレクトされたユーザーがヘッダーやフッターにある国別のリンクをクリックします。例えば、 ”US　サイト”　のリンクをクリックします。この時点でクッキーを設定します。もし国別のドメインが違う場合、別の 国のドメインを設定できない場合は、UrlReferrerを確認し、クッキーを設定することができます。 if (HttpContext.Current.Request.UrlReferrer != null && (HttpContext.Current.Request.UrlReferrer.Host.ToLower().Contains(“sanbox.jp”)) { SetCookie(“usVisitOverride”, “true”); } /// <summary> […]

概要: 最近プロダクションにて特定の時間帯にて、CUPが１００％となり、サイトのロード速度が 遅くなってしまいました。その原因は特定のIPより、特定のページへのリクエストを継続的 にされていたことが原因だった。そのトラブルシューティングする際に、IISマネージャーの リクエスト一覧を使用していましたが、これは案外知られていないようで、メモ書きとして 書き留めます。     サイトのロード速度が落ちるのはいろいろな原因があります。その一つのチェックポイントとして、 CPUの使用状況の確認です。その際によく、IISのWorkerプロセスがCPUをリソースを使っている ことが分かりながら、その原因を突き止めるにはいろいろなツールがあり、また、サイトコアの ログを見ることも一つの手です。今回のように、特定の時間帯で起きることで、最初にインディクス 再構築が原因かと思ってけど、なにかリクエストーされているかを見てみると、特手のページへ 特定のIPよりサイトの速度を落としていることをが分かった。その際に使ったツールをはIIS マネージャーにあるリクエストの一覧でした。   もし、この機能がインストールされていなかったら、下記の手順にて、インストールすればいい。 Server Manager -> Add Roles. Web Server (IIS) Web Server Health and Diagnostics Request Monitor   リクエストを見るには、IISマネージャーを起動し、WorkerProcessesを選択   ここにて、現時点のリクエストの一覧を見ることができます。   例えばお客さんより、ページのレスポンスが遅いと言えれ、このにてサーバーのリスエストの情報が 見ることができます。   例えば、TimeElapsedのコラムをみると、特手のページが時間がかかっていることが一目瞭然です。 この場合はカタログのページが時間がかかっているので、カタログ関連のトラブルシューティングすればいい。またフィールダーを使て、簡単に時間がかかるれクエストを特定することができます。リアルタイムなので、F5で最新のリクエストが表示されます。   また、appcmdを使って、同じリクエストをコマンドプロンプトにて見ることができます。 C:\Windows\System32\inetsrv>appcmd list requests もし、データーをコピーしたいなら、CLIPを使えばいい。 C:\Windows\System32\inetsrv>appcmd list requests | clip さらに、下記のように、特定のサイトにて時間がかかるリクエストをフィールダーすることができます。 例えば、二分以上かかるリクエストの一覧を見るには： […]