v7 v8
推播通知頻道變更
- 適用對象：
- Campaign v8 Client Console
建立對象：
- 經驗豐富
- 管理員
您可以使用Campaign在iOS和Android裝置上傳送推播通知。 為此，Campaign需仰賴行動應用程式訂閱服務。
Android Firebase Cloud Messaging (FCM)服務的一些重要變更將於2024年發行，可能會影響您的Adobe Campaign實施。 您可能需要更新Android推送訊息的訂閱服務設定，才能支援此變更。
此外，Adobe強烈建議改用權杖式連線來連線APN，而非更安全、更可擴充的憑證式連線。
Google Android Firebase Cloud Messaging (FCM)服務
哪些部分有所變更？
Google持續改善服務，其中舊版FCM API將於 2024年7月22日 終止服務。 在Google Firebase檔案中進一步瞭解Firebase雲端通訊HTTP通訊協定。
Adobe Campaign Classic v7和Adobe Campaign v8已支援最新API來傳送推播通知訊息。 不過，有些舊版實作仍需仰賴舊版API。 必須更新這些實作。
您有受到影響嗎？
如果您目前的實作支援使用舊版API連線至FCM的訂閱服務，則會受到影響。 轉換至最新的API是必須的，這樣才能避免任何服務中斷。 在這種情況下，Adobe團隊會與您聯絡。
若要檢查您是否受到影響，您可以依照以下篩選條件來篩選您的 服務與訂閱：
-
如果您的任何使用中推播通知服務使用 HTTP （舊版） API，此變更將直接影響您的設定。 您必須檢閱目前的設定，並依照下方所述移至較新的API。
-
如果您的設定僅使用 HTTP v1 API來處理Android推播通知，則表示您已符合規範，不需要您採取任何進一步的動作。
如何更新？
先決條件
-
需要Android Firebase Admin SDK服務的帳戶JSON檔案，才能將行動應用程式移至HTTP v1。 在Google Firebase檔案中瞭解如何取得此檔案。
-
針對Campaign Classic v7,20.3.1版本已新增支援HTTP v1。 如果您的環境執行於舊版，轉換至HTTP v1的先決條件是將環境升級至最新的Campaign Classic組建。 若為Campaign v8，所有發行版本都支援HTTP v1，且不需要升級。
-
身為Campaign Classic v7內部部署使用者，您必須升級行銷和即時執行伺服器。
-
對於混合、託管和受管理的Cloud Service部署，除了下面的轉換程式外，請聯絡Adobe以更新您的即時(RT)執行伺服器。
-
關於Android路由外部帳戶：
-
作為Campaign Classic v7內部部署或混合使用者，請檢查您的Android路由外部帳戶是否已設定
androidPushConnectorV2.js。 深入瞭解Campaign Classicv7檔案。 -
對於混合、託管和受管理的Cloud Service部署，您還必須與Adobe客戶服務團隊連線，以驗證在Android路由您中間來源伺服器的外部帳戶中選取
androidPushConnectorV2.js (nms)聯結器。
-
轉換程式
若要將環境移至HTTP v1，請遵循下列步驟：
-
瀏覽至您的 服務與訂閱 清單。
-
列出使用 HTTP （舊版） API版本的所有行動應用程式。
-
針對這些行動應用程式的每一個，將 API版本 設定為 HTTP v1。
-
按一下 Load project json file to extract project details… 連結，直接載入您的JSON金鑰檔案。
您也可以手動輸入下列明細：
- Project Id
- Private Key
- Client Email
-
按一下 Test the connection 以檢查您的設定是否正確，以及行銷伺服器是否具有存取FCM的許可權。 請注意，針對中間來源部署，Test connection 按鈕無法檢查伺服器是否擁有Android Firebase雲端通訊(FCM)服務的存取權。
-
您可以視需要以約 Application variables 擴充推送訊息內容，作為選項。 這些都是可完全自訂的專案，而且是傳送至行動裝置的訊息裝載的一部分。
-
按一下 Finish，之後 Save。
以下是FCM裝載名稱，可進一步個人化您的推播通知。 此處提供這些選項的詳細資料。
訊息類型可設定的訊息元素（FCM裝載名稱）可設定的選項（FCM裝載名稱）資料訊息N/Avalidate_only通知訊息title，內文， android_channel_id，圖示，聲音，標籤，顏色，點按動作，影像，提示，粘性，可見度，通知優先順序，通知計數validate_only
NOTE更新現有範本
轉換HTTP v1完成後，您必須為Android推播通知更新 傳遞範本，以增加批次訊息的數量。 若要這麼做，請瀏覽至您的Android傳遞範本的屬性，並在 傳遞 索引標籤中，將訊息批次數量設定為 256。 將此變更套用至Android傳遞使用的所有傳遞範本，以及所有現有的Android傳遞。
您也可以更新在升級至支援HTTP v1的版本之前建立的現有傳遞和傳遞範本。 若要執行此動作：
-
若為「受管理的Cloud Service」或「託管」客戶，請聯絡Adobe以更新您現有的Android傳遞範本。
-
若為內部部署環境，請下載
fcm-httpv1-migration.js指令碼並執行，如下所述。
CAUTION指令碼必須在您的內部部署行銷執行個體上執行。更新現有傳遞和範本的步驟（僅限內部部署）若要修補在升級至支援HTTP v1的版本之前建立的所有傳遞和傳遞範本，請遵循下列步驟：
-
將您現有的傳遞和傳遞範本匯出至套件中，以便在修補期間發生未預期的問題時能夠還原它們。
-
在Posgresql中執行以下命令：
pg_dump -Fp -f /sftp/<db_name>-nmsdelivery-before_rd_script.sql -t nmsdelivery -d <db_name> -
根據預設，指令碼處於
dryrun模式，您可以在該模式中啟動它，以檢查是否需要修補某些傳遞。命令
nlserver javascript -instance:<instance_name> -file fcm-httpv1-migration.js輸出
... HH:MM:SS > Processing delivery (id:123456, label:'Deliver on Android - New', name:'DM1234') HH:MM:SS > Dry run: Would update androidCheckParams for delivery (id:123456, label:'Deliver on Android - New', name:'DM1234') HH:MM:SS > Processing delivery (id:567890, label:'Deliver on Android - New', name:'DM5678') HH:MM:SS > Dry run: Would update androidCheckParams for delivery (id:567890, label:'Deliver on Android - New', name:'DM5678') ... HH:MM:SS > Summary (XYZ processed deliverie(s) or delivery template(s)): HH:MM:SS >> - X had not patchable androidCheckParams formula! HH:MM:SS > - Y had androidCheckParams formula patched. HH:MM:SS > - Z ignored as alreading having androidCheckParams formula patched.NOTE需要手動更新not patchable傳遞。 可在紀錄中找到其ID。 -
在執行模式中以下列方式執行指令碼以更新傳送：
nlserver javascript -instance:<instance_name> -file fcm-httpv1-migration.js -arg:run
-
對我的Android應用程式有何影響？
Android Mobile應用程式的程式碼不需要任何特定變更，通知行為也不應變更。
不過，使用HTTP v1時，您可以使用 HTTPV1 additional options 進一步個人化推播通知。
您可以：
- 使用 Ticker 欄位來設定通知的提示字元文字。
- 使用 Image 欄位來設定要在通知中顯示的影像URL。
- 使用 Notification Count 欄位設定新未讀取資訊的數量，以直接顯示在應用程式圖示上。
- 將 Sticky 選項設為false，讓使用者按一下通知時，通知會自動關閉。 如果設為true，則即使使用者按一下通知，仍會顯示通知。
- 將通知的 Notification Priority 層級設定為預設、最低、低或高。
- 將通知的 Visibility 層級設定為公開、私人或機密。
有關 HTTP v1 additional options 以及如何填寫這些欄位的詳細資訊，請參閱FCM檔案。
Apple iOS推播通知服務(APN)
哪些部分有所變更？
依照Apple的建議，您應使用無狀態驗證權杖來保護與Apple推播通知服務(APN)的通訊。
權杖型驗證提供與APN無狀態通訊的方式。 無狀態通訊比憑證式通訊更快，因為無狀態通訊不需要APN查閱憑證或其他與您的提供者伺服器相關的資訊。 使用權杖型驗證還有其他優點：
-
您可以使用來自多個提供者伺服器的相同Token。
-
您可以使用一個Token為貴公司的所有應用程式散發通知。
在Apple開發人員檔案中進一步瞭解與APN的權杖型連線。
Adobe Campaign Classic v7和Adobe Campaign v8同時支援權杖型和憑證型連線。 如果您的實施仰賴憑證式連線，Adobe強烈建議您將其更新為權杖式連線。
您有受到影響嗎？
如果您目前的實施仰賴憑證式請求來連線至APN，則會受到影響。 建議轉換為權杖型連線。
若要檢查您是否受到影響，您可以依照以下篩選條件來篩選您的 服務與訂閱：
-
如果您的任何使用中推播通知服務使用 憑證式驗證 模式(.p12)，則應檢閱您目前的實作，並將其移至 權杖式驗證 模式(.p8)，如下所述。
-
如果您的設定僅針對iOS推播通知使用 權杖式驗證 模式，則您的實作已經是最新的，不需要您採取任何進一步的動作。
如何更新？
先決條件
-
針對Campaign Classicv7，已在20.2發行版本中新增支援 權杖式驗證 模式。 如果您的環境執行於較舊的版本，此變更的先決條件是將您的環境升級至最新的Campaign Classic組建。 對於Campaign v8，所有發行版本都支援 權杖式驗證 模式，且不需要升級。
-
您需要APNs驗證Token簽署金鑰才能產生您的伺服器所使用的Token。 如Apple開發人員檔案所述，您向您的Apple開發人員帳戶要求此金鑰。
-
對於混合、託管和Managed Services部署，除了下列轉換程式外，請聯絡Adobe以更新即時(RT)執行伺服器。 中間來源伺服器不受影響。
-
身為Campaign Classic v7內部部署使用者，您必須升級行銷和即時執行伺服器。 中間來源伺服器不受影響。
轉換程式
若要將iOS行動應用程式移至權杖型驗證模式，請遵循下列步驟：
-
瀏覽至您的 服務與訂閱 清單。
-
列出使用 憑證式驗證 模式(.p12)的所有行動應用程式。
-
編輯每個行動應用程式，並瀏覽至 憑證/私密金鑰 標籤。
-
從 驗證模式 下拉式清單中，選取 權杖型驗證 模式(.p8)。
-
填寫APNs連線設定 Key Id、Team Id 和 Bundle Id，然後按一下 Enter the private key… 以選取您的p8憑證。
-
按一下 Test the connection 以檢查您的設定是否正確，以及伺服器是否具有APN的存取權。 請注意，對於中間來源部署，Test connection 按鈕無法檢查伺服器是否擁有APN的存取權。
-
按一下 Next 開始設定生產應用程式，並依照上述步驟執行。
-
按一下 Finish，之後 Save。
您的iOS應用程式現在已移至權杖型驗證模式。