Zenn
💡

ServiceNowで独自に実装したServicePortal(EmployeeCenter)でSave as Draftを有効にしてみた

2024/04/19に公開
ServiceNow
tech

3行まとめ

なぜやったのか

リリースノートを読んで「カタログ項目フォームを下書きとして保存」が実装されたことを知りワクワクしていた...!!!!!(ついにキター)

いざ開発環境をアップグレードしてみるとOOTBのspやescでは確認できたが、独自に実装していたescでは有効にならず「どうして」となっていた。

脳内会議の結果はユーザビリティを考えても「あった方が良い」という判断をした(光の速度)。
ヤルゾー。

そもそもなんで独自実装？

社で運用するときに「あれは追加したい」や「これは隠したい」などの要件はどうしても出てきます。
「デザインやレイアウトはこうしたい」などあるあるだと思います。
OOTBに手を入れるのが一番簡単ですが、OOTBに手を入れてしまうとアップグレードしたときに以下のことが起きがちかなと思います

  • Revert to Basesystemすると一から再カスタマイズが必要になる
    • カスタマイズ具合によっては工数が莫大になる可能性もある
  • 頑張ってマージするにしてもOOTBの動作が確認できない
    • いくつも非本番環境を持っていてOOTB参照用などで使えるとOOTBの最新状態を確認できるかも？
  • Revert to Basesystemやマージをしないと最新機能の恩恵を享受できない
    • SaaS/PaaSを使う旨味の一つが失われてしまう

そこでイニシャルコストは掛かりますが、独自実装をしておくことで以下を実現しています

  • OOTBは残して可能な限り独自に実装する
    • アップグレード時などにto reviewが発生してもOOTBはノーリスクでRevert to Basesystemで対応しOOTBの最新状態にできる
  • OOTBの最新状態を確認して欲しい機能があったら選んで取り込める
    • 美味しいとこ取りができる

さて本題

今回はどのように調査して対応したのかを書いてみようと思います

1. 動作を確認

1. 独自に作成したescとOOTBのescで動作の違いについて確認した

独自

https://<your-instance>.service-now.com/<your-portal-url-suffix>?id=sc_cat_item&sys_id=<sc_cat_item.sys_id>

OOTB

https://<your-instance>.service-now.com/esc?id=sc_cat_item&sys_id=<sc_cat_item.sys_id>

確認結果

独自のescには表示されず、OOTBのescでは表示された。
ページに使用されているwidgetが異なったので、widgetによって対応/非対応がわかれること疑った

2. 独自に作成したescとOOTBのsp(service portal)で動作の違いについて確認した

独自

https://<your-instance>.service-now.com/<your-portal-url-suffix>?id=sc_cat_item&sys_id=<sc_cat_item.sys_id>

OOTB

https://<your-instance>.service-now.com/sp?id=sc_cat_item&sys_id=<sc_cat_item.sys_id>

確認結果

独自のescには表示されず、OOTBのspでは表示された。
ページに使用されているwidgetが同一だったことで、widgetによって対応/非対応がわかれる可能性が消えた
-> portalの設定によって対応/非対応がわかれることを疑った

2. 設定を確認

1. 独自に作成したescとOOTBのescで設定の違いについて確認した

Portalsの画面で設定項目を目Grep　👁️　した。

明確にsave as draftに関連しそうな差分は発見できなかった

2. 表示に使用しているwidgetのコードを確認

widgetは SC Catalog Item を対象にした

https://<your-instance>.service-now.com/sp_config?id=widget_editor&sys_id=3c29786e87133200e0ef0cf888cb0bdf

HTML

client scriptでの処理 c.showDraftButtons() とsever sideから渡されている値 !data.is_draft_item を使って判断していることがわかった

ng-if="c.showDraftButtons() && !data.is_draft_item"

client script

showDraftButtons() の実装ではページのオプション options.hide_save_as_draft_button と server sideから渡されている値 data.draft_buttons_hidden_via_property を使って判断していることがわかった

server side

data.draft_buttons_hidden_via_property をどのように設定しているかを確認した

data.draft_buttons_hidden_via_property = (gs.getProperty('glide.sc.disable.save_as_draft') == 'true') || (gs.getProperty('glide.sc.enable.save_as_draft.portal.' + data.portal_suffix) != 'true');

2つのプロパティを使ってどちらかがTrueの場合に data.draft_buttons_hidden_via_property がtrueと設定されることがわかった

  • gs.getProperty('glide.sc.disable.save_as_draft'
    • なにもなかった
      　　　　　　　　
  • glide.sc.enable.save_as_draft.portal.' + data.portal_suffix
    • portalのsuffixが含まれるプロパティのため glide.sc.enable.save_as_draft.porta だけで検索
      • 値を発見。OOTBの思想ではこちらを使っていると理解した
        　　　　
    • escの表示を行いたいので glide.sc.enable.save_as_draft.portal.esc を参照してみた

実施した対応

上記で参照したプロパティ(glide.sc.enable.save_as_draft.portal.esc)　を参考にして新規にプロパティを作成した

  • name
    • glide.sc.enable.save_as_draft.portal.<your-portal-url-suffix>
  • value
    • true

作成後に独自に実装したescを見に行くとsave as draftボタンが表示されるようになった。

EOF

Discussion