0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@191ryu(191 Ryu)

MuleSoft Platform Integrationアーキテクト　お勉強②

0
Last updated at Posted at 2026-10-26

はじめに

Salesforce 認定 MuleSoft Platform Integration アーキテクト（旧称：MCIA - Level 1） の受験に向けて、「いろんな用語は聞いたことがあるけれど、MuleSoft全体のアーキテクチャが頭の中で繋がっていない…」という状態から、約5時間で一気に全体像の理解と頻出パターンの暗記を完了させるためのまとめ記事です。

怪しい噂や解答が割れるような曖昧な内容は一切排除し、MuleSoft公式ドキュメントの仕様で100%裏付けが取れる確実な知識・頻出の判断基準だけを厳選して体系化しています。

📌 試験の基本情報（おさらい）

  • 正式名称：Salesforce 認定 MuleSoft Platform Integration アーキテクト（MCIA）
  • 問題数 / 試験時間：60問（単一・複数選択式） / 120分
  • 合格ライン：70%（42問以上の正解）
  • 試験の本質：実装知識（MCDレベル）ではなく、**「非機能要件（可用性・性能・セキュリティ・保守性）を満たすために、どのデプロイモデル・コンポーネント・トランザクション戦略・ネットワーク構成を選択すべきか」**というトレードオフの判断力が問われます。

第1章：ランタイムプレーン・ネットワーク・高可用性（HA）設計

インフラ・デプロイメントの選択問題は、公式仕様の「絶対的な制約条件」を覚えておくだけで消去法で即答できます。

1.1 デプロイモデル（ランタイムプレーン）の選択基準

デプロイモデル 構造・特徴 試験で狙われる決定的な選択基準（公式仕様）
CloudHub 1.0 MuleSoft管理のAWS EC2ベース
（1ワーカー ＝ 1専用VM ＝ 1アプリ）		 ・Windows OS非対応（Linuxベースのみ）
・ワーカー間でファイルシステムや log4j2.xml の共有不可
・Muleドメインプロジェクト非対応
・ゼロダウンタイム再デプロイ：新ワーカーが起動完了するまで旧ワーカーが処理を続け、起動後に切り替わる
Runtime Fabric (RTF) コンテナ（Docker / Kubernetes）ベースのランタイム ・Windows Server非対応
・Muleドメインプロジェクト非対応
・ポート競合管理が不要：各アプリが独立したコンテナ内で同じポート（8081等）をリッスンでき、Ingressがルーティングするため、アプリの書き換え不要＆DevOpsのポート管理が不要
Customer-hosted
（顧客ホスト型）		 顧客管理のOS・VMに直接Muleランタイムをインストール ・「Windows Serverが必須（専用コネクタ等）」と言われたらこれ一択
・1つのランタイム上に複数アプリを同居でき、MuleドメインプロジェクトでHTTPリスナーや接続設定を共有可能
・共有ファイルシステムで 1つの log4j2.xml や証明書を複数アプリから直接参照可能
  • 💡 顧客ホスト型での証明書ローテーション最小化
    複数アプリが同じポート・同じHTTPS証明書を使い、証明書が頻繁に更新される場合：
    1. HTTPリスナー設定は 「Muleドメインプロジェクト」 に定義して全アプリで共有する。
    2. サーバー証明書（Keystore） はJARに含めず、「Muleランタイムのクラスパス上の外部共有ファイルシステム（$MULE_HOME 以外のフォルダ）」 に配置する（証明書更新時の再ビルド・再デプロイが不要になる）。

1.2 CloudHubネットワーク：SLB vs DLB と FQDN

比較項目 Shared Load Balancer (SLB) Dedicated Load Balancer (DLB)
前提条件 CloudHub標準提供（無料・設定不要） Anypoint VPCの作成が必須（VPC内に配置される）
独自ドメイン / 証明書 ❌ 不可（*.cloudhub.io 証明書のみ） ⭕ 可能（カスタムX.509証明書・独自ドメインを設定可能）
双方向TLS (mTLS) ❌ 不可（クライアント証明書検証に非対応） ⭕ 可能（クライアント証明書検証をサポート）
IPホワイトリスト制限 ❌ 不可 ⭕ 可能（IP Allowlistでアクセス制御可能）
URLマッピングルール ❌ 不可 ⭕ 可能（URLパスに応じて異なるMuleアプリへ振り分け可能）
  • CloudHubのFQDN（DNS名）の決まり方：<アプリ名>.<リージョン>.cloudhub.io となるため、「アプリケーション名」と「リージョン（地域）」の両方で決まる。
  • オンプレLBからCloudHubへの移行（独自ドメイン維持）：APIプロキシを別途作る必要はなく、**「DLBにカスタムX.509証明書とマッピングルールを設定し、社内DNSのCNAMEレコードがDLBのAレコードを指すように変更する」**のが最もシンプルで低コスト。

1.3 Anypoint VPCの接続方式とIP（CIDR）サイジング計算

  • 同一リージョン内の顧客AWS VPCとの接続 ➡️ VPC Peering（VPCピアリング） または Transit Gateway（CIDRブロックが重複していないことが条件）。
  • オンプレミスのデータセンターとの接続 ➡️ Anypoint VPC ＋ IPsec VPNトンネル（またはAWS Direct Connect） ＋ 双方のファイアウォールルール許可。
  • 【必出計算】Anypoint VPCのIPアドレス（CIDR）サイジング
    ゼロダウンタイム再デプロイ時に新旧ワーカーが同時に動くため、常時稼働ワーカー数の2倍のIPが必要です。
    • 公式：$\text{必要最小IP数} = \text{環境数} \times \text{アプリ数} \times \text{ワーカー数} \times 2$
    • 計算例：3環境 × 150アプリ × 2ワーカー × 2（ゼロダウンタイム） ＝ 1,800 IPs
    • 1,800以上を満たす最小ブロックは $2^{11} = \mathbf{2,048\text{ IPs}}$（/21 すなわち 10.0.0.0/21）。
    • ※暗記用：/24=256、/23=512、/22=1024、/21=2048。

1.4 クラスター・高可用性（HA）・負荷計算

  1. Customer-hostedクラスターのプライマリノード昇格
    • ファイルやDBポーリング（On Table Row）は競合防止のためプライマリノードのみが実行する。
    • プライマリノード（Node A）が停止すると、セカンダリノード（Node B）が自動的にプライマリへ昇格しポーリングを引き継ぐ。その後、旧プライマリ（Node A）が再起動して復帰してもプライマリには戻らず、昇格したNode Bがそのままプライマリとしてポーリングを続ける。
  2. クラスターへのノード追加・停止時の確定ルール
    • ノード追加時：Muleクラスターは新ノードを自動認識するが、外部の監視ツールやログ収集ツールが新ノードを認識するための設定は必要。
    • 2ノード ➡️ 4ノードへ増設：ラウンドロビンLB配下のステートレスAPIでは、**「各ノードが受信するリクエスト数が50%削減される」**ことが保証される。
    • 4ノード ➡️ 2ノードがダウン：残りのノードに十分なキャパシティ余裕がある場合、**「残りの各ノードが受信するリクエスト数が100%増加（2倍）する」**ことが保証される。

第2章：API主導の接続性・C4E・データモデル設計

2.1 C4E（Center for Enablement）とExchange資産

  • C4Eの定義とKPI
    C4Eは開発を代行する中央組織ではなく、各事業部門（LOB）がセルフサービスで迅速に開発できるよう支援する横断組織。
    C4Eの成功を測る直接のKPIは 「各事業部門のAPIのうち、C4Eで規定・公開された資産（APIやテンプレート）を再利用・接続している数」。
  • プロジェクトスケルトンの公開
    開発者がベストプラクティスに沿って実装を開始するための骨格をExchangeで共有するには、「主要なコンポーネントと最小限の統合ロジックを備えたMuleアプリケーションテンプレート（Mule Application Template）」 を使用する。
  • 半技術的なステークホルダーとの仕様共有
    半技術的なユーザーと熟練コンシューマーの両方が統合設計を理解・対話できるようにするには、**「APIノートブック（API Notebook）を含み、統合設計を詳述したページを持つAnypoint Exchangeエントリ」**を作成する。

2.2 API主導の接続性（3層構造）と共通データモデル（CDM）

  • 3層構造の基本と「Process API省略」の例外
    • 原則：1つのバックエンドシステムにつき1つのSystem APIを作る（1つのSystem APIが複数バックエンドに直結するのはNG）。
    • 例外（Process APIのスキップ）：特定のクライアントから1つのレガシーシステムへデータを送るだけで、他システムでのデータ再利用やオーケストレーションが一切ない場合は、Process APIとCDMを作らず 「Experience API ➡️ System API」と直接つなぐのが最も効率的。
    • 配信方式の追加への備え：現在SFTPでファイルを受け取ってBatch処理しており、将来HTTP POST等で送るベンダーが増える場合は、**「ファイル受信用API（Experience層）＋ Batch処理を行うProcess API ＋ DB保存を行うSystem API」**に分離する。
  • 共通データモデル（CDM）の2大原則
    1. Experience APIは通常CDMでモデル化しない（クライアント固有の画面・形式に合わせるため）。CDMは主にProcess APIで使用する。
    2. すべてのデータ型を無理にCDMで定義する必要はない。
    • ※なお、データモデルはAPIで再利用されるため、CDMの変更は当然API実装に影響する。

2.3 仕様言語とプロトコルの確実な知識

  • REST APIの標準仕様定義言語 ➡️ OpenAPI仕様 (OAS) または RAML（※YAMLはフォーマットであり仕様言語ではない）。
  • SOAP Webサービスのデータ構造定義言語 ➡️ WSDLの <types> セクション内でデータ構造を定義する言語は XSD（XML Schema Definition）。
  • RESTではなくSOAP / WS-* を選ぶべきケース ➡️ 「すべてのコンシューマーが有効なSAMLトークンを送信してサービスを保護する必要がある場合」（WS-SecurityがSAMLトークン検証を標準サポートしているため）。
  • Salesforce Core連携の2大プロトコル ➡️ REST API と gRPC（Pub/Sub API）。
  • 大量データ（数千万件のCSV等）の日次DWH複製スタイル ➡️ バッチトリガーによるデータ統合（Batch-triggered data integration）。

第3章：ステート管理・VM永続キュー・バッチ＆ストリーム処理

3.1 CacheスコープとObject Store V2の共有境界

  • 特定オペレーション（例：GET /testResult のみ）の応答性改善
    API全体のポリシーではなく、そのオペレーションのフロー内部に 「Cacheスコープ」 を配置する。
  • Object Store V2の共有ルール（超頻出）
シナリオ 使用する手段 理由・認証手順
同一Muleアプリの複数CloudHubワーカー間でキャッシュやWatermarkを共有 Object Store Connector
（永続Object Store）		 同じアプリの複数ワーカー（または同一クラスター内ノード）間であれば、追加設定なしでObject Store Connectorからそのまま自動共有できる。
異なるMuleアプリ間でのデータ共有・削除
（別アプリからの削除、または RTF上のアプリ ⇔ CloudHubのOS v2間）		 Object Store v2 REST API 異なるアプリ間やRTF⇔CloudHub間では、Connectorでの直接共有は不可。
【認証手順】
1. Object Storeから Client ID と Client Secret を取得
2. Access Managementの /oauth2/token（accounts/oauth/token） からトークンを取得
3. Bearerトークンで Object Store v2 REST API を呼び出す

3.2 CloudHubにおけるVMキューの挙動

  • ワーカークラッシュ時のデータ損失ゼロ（Zero message loss）
    フロー内のVM設定が TRANSIENT のままでもコードを直す必要はない。Runtime Managerのアプリ設定で「Persistent queues（永続キュー）」を有効にし、ワーカーを2台以上にするだけでデータ損失を防げる。
  • 複数CloudHubワーカーでの永続VMキューの消費ルール
    永続VMキューを有効にして複数ワーカーにデプロイした場合、メッセージは正確なラウンドロビン（均等配分）にはならない。「各メッセージは、利用可能な任意の（arbitrary）ワーカーの1つに、非決定論的・非ラウンドロビン方式でルーティングされ、少なくとも1回（at least once）処理される」。

3.3 スコープ・ルーターとBatch Jobの内部構造

  • スコープ・ルーターの使い分け
    • 複数APIを並列呼び出しして応答時間を短縮し結果を統合 ➡️ Scatter-Gather。
    • 元の順序通り（Sequentially）にレコードを処理し、1件エラーが出ても残りの処理を継続する ➡️ For Eachスコープ ＋ On Error Continue（※Parallel For Each や Batch Job は順序が崩れるためNG）。
    • すべての検証が失敗したときのみエラーをスローし、エラーを集計する ➡️ VALIDATION:ANY スコープ（例外は VALIDATION:MULTIPLE となる）。
  • Batch Jobの内部動作とチューニング
    • 大量CSV（数百万件）の変換とDB登録（順序不問） ➡️ Batch Job ＋ Bulk Insert。
    • Batch Jobの内部スレッドとレコード処理：
      1. 各バッチジョブはバッチステップの処理に 複数のスレッド（Multiple threads） を使用する。
      2. 各バッチステップのインスタンスは、ペイロードとして 一度に1つのレコード（one record at a time） を受け取る。
      3. レコードは 複数のバッチステップ内、およびバッチステップ間で並列に処理される。
    • Batch Jobの高速化：CPUやメモリに余裕があるのに遅い場合は、他アプリに影響するランタイム設定ファイルは触らず、「Batch Jobスコープの同時実行数（maxConcurrency）とレコードブロックサイズ（Block size）を大きくする」。

3.4 ストリーミング・データフォーマット・クラスローダー

  1. 反復可能なインメモリストリーム（Repeatable In-memory Stream）の上限超過
    maxBufferSize = "512" (KB) の設定に対し 1,000KB のペイロードが来ると、バッファを拡張できず ランタイムエラー（STREAM_MAXIMUM_SIZE_EXCEEDED）がスローされる。
  2. 大規模XML/CSV処理の鉄則
    ヒープメモリ枯渇（OutOfMemory）を防ぐため、「単一のJavaオブジェクト（POJO / DOM）に変換せず、ストリームのまま順次処理する」。
  3. application/dw フォーマットの注意点
    • デバッグ用途であり性能が低いため本番環境（Production）では非推奨。
    • 使用時は onlyData=true プロパティの設定が必要。
  4. MuleSoft Serialization API（ObjectSerializer.java）の特徴
    • シリアライズおよびストリーミング時に OutputStream を渡す。
    • 入力ソースとして InputStream を使用できる（かつスレッドセーフ）。
  5. Javaライブラリのバージョン競合（クラスローダー）
    1つのアプリ内の2つのモジュールが異なるバージョンの同一クラス（Joda-Time等）を返す場合、デプロイは成功するが片方のバージョンのみがロードされ、もう片方で実行時エラーが発生しやすくなる。

第4章：トランザクション・非同期連携・障害回復パターン

4.1 トランザクション管理（Local / XA / Saga）

  • トランザクションに参加できる3大コネクタ（これ以外はすべて非対応）

    ✅ Database (JDBC) ／ ✅ JMS ／ ✅ VM
    （※ HTTP / REST、Anypoint MQ、SFTP、File、Object Store はトランザクション非対応）

  • XAトランザクションの利点と制約
    • 2つのDB同期でXAを使う最大の利点は 「一貫性を確保する（Ensure consistency）」 こと（性能は低下しレイテンシーは増える）。
  • 複数のSystem API（HTTP REST）をまたぐロールバック設計
    HTTP/RESTはステートレスのためXAトランザクションは組めない。「各System API内部でローカルトランザクションを実装し、API間はSagaパターンと補正アクション（Compensating actions）で取り消す」。
  • 信頼性パターン（Reliability Pattern）の注意点
    • パフォーマンスに影響がある（Performance impact）。
    • 同一トランザクション内で複数のメッセージソースを持つことはできない。
  • XAを使わずに「JMS読み取り＋2つのDB挿入」でデータ損失と不整合を防ぐ順序
    1. JMSメッセージを読み取る（まだACKしない）
    2. 1つのDBトランザクション内で両方のDB挿入を実行する
    3. すべてのDB挿入が成功した最後に、JMSメッセージをACK（確認応答）する

4.2 非同期メッセージング（Anypoint MQ / JMS）

  • Anypoint MQを使うべきケース
    • ポート80/443（HTTPS）のみ許可された環境から、社内外の複数コンシューマーへイベントをブロードキャストする ➡️ Anypoint MQ（Exchange）。
    • DBのSELECTが「1時間10回」に制限されており、変更を10秒以内に複数システムへ同期する ➡️ On Table Row のポーリングでは制限を超えるため、**「DBトリガー＆ストアドプロシージャからMuleへRESTコール ➡️ Anypoint MQ Exchangeへパブリッシュ ➡️ 各サブスクライバーMuleアプリが同期」**する。
  • JMS Queue と Topic の使い分けとクラスター設定
    • 1対1（単一のコンシューマーのみが消費するコマンド） ➡️ JMS Queue。
    • 1対多（関心のある全コンシューマーが消費するイベント） ➡️ JMS Topic。
    • クラスター環境でJMS Queueの並列処理性能を最大化する設定：Queueは全ノードで受信しても重複しないため、primaryNodeOnly = false（全ノードで受信）かつ numberOfConsumers > 1（複数スレッド消費） に設定する。
  • Competing Consumers（競合コンシューマー）でのCorrelation ID保持先
    JMSキュー ➡️ 同期で冪等なSOAP呼び出し ➡️ 応答JMSキューの一連の処理は単一スレッドの1フロー内で完結し、ノード障害時はJMSキューから再処理されるため、Object Storeへの保存は不要。Correlation IDは「Muleイベント変数（Variables）または属性（Attributes）」に保持する。

4.3 障害回復：再接続戦略 vs Until Successful vs DLQ

  • JMSブローカーが定期メンテで10分間停止する ／ DBが4時間停止した後に復旧した
    ➡️ コネクタの 再接続戦略（Reconnection strategy） により、アプリの再起動や再デプロイなしで自動回復できる。
  • 可用性の低いレガシーバックエンドAPI（HTTP等）の一時的なダウンタイム対策
    ➡️ API呼び出しを Until Successful スコープ で囲んでリトライする。
  • 一時的な障害は自動リトライし、バックエンドに拒否された注文だけを手動処理に回す
    ➡️ Until Successful（またはActiveMQのリトライ） ＋ ActiveMQのDead Letter Queue (DLQ) ＋ On Errorスコープ を組み合わせる。

第5章：セキュリティ・監視・ロギング・CI/CD・テスト＆SLA

5.1 セキュリティ設計（mTLS / 隠しプロパティ / OAuth / IdP & RBAC）

  1. 双方向TLS（mTLS）の鍵配置ルール
    • HTTPリスナーでKeystoreとTruststoreの両方を設定する理由は 「HTTPクライアントとのTLS相互（双方向）認証（mTLS）のサポート」。
    • Keystore ＝ 自分自身の秘密鍵（Private Key）と公開鍵（Public Key） を保存。
    • Truststore ＝ 通信相手の公開鍵（Public Key） を保存。
  2. Runtime Managerでのプロパティ非表示化（Hidden Properties）
    dbPassword 等を画面上で *** に隠すには、mule-artifact.json の secureProperties にプロパティ名を記載する。
  3. 外部OAuth 2.0 APIの呼び出し
    自前でトークン取得フローを作る必要はなく、HTTP Connector（HTTP Request設定）の標準Authentication機能で自動取得できる。
  4. Anypoint Security for Edge と JSON Threat Protection
    • RTFでEdgeセキュリティポリシーを使う前提条件：「Anypoint Security for Edgeのライセンス権限（Entitlement）」 と 「RTFのインバウンドトラフィックの許可設定」。
    • 認証なしの公開API（モバイル/Web向け）を巨大な悪意あるJSONから守るポリシー ➡️ JSON脅威保護（JSON Threat Protection）ポリシー。
  5. 外部IdP（SSO）とRBACの境界
    • SSOの標準規格は SAML 2.0 と OpenID Connect (OIDC) の2つ（フェデレーションID管理）。
    • 複数の事業部門（LOB）ごとに複数のIdPを使わせる機能 ➡️ クライアント管理（Client Management）。
    • ビジネスグループではなく常にマスター組織レベルで行う設定 ➡️ 役割と権限の設定（Roles and permissions）。
    • 外部IdP連携時でも、常にAnypoint Platform側で制御しなければならない項目 ➡️ 「Anypoint Platformの権限（Permissions）をロール（Roles）に割り当てること」。
    • 特定ユーザーがExchangeでアセットを発見（Discover）できるかを制限するもの ➡️ 「ユーザーが属するチーム（Teams）」。

5.2 監視・ロギング・監査・トレーシング

  • Muleと非Muleの両方のAPIを外部からヘルスチェック監視 ➡️ API Functional Monitoring。
  • WebStoreバックエンドから全APIで同一Correlation IDをログ出力（最小コード）
    ➡️ WebStoreが X-Correlation-ID HTTPヘッダーを生成して送信するだけ（Mule側は自動で認識・下流伝播するためコード変更不要）。
  • ロギング：同期 vs 非同期 と Splunk連携
    • 同期ロギングの特性：進行中のトランザクション内の同期ロギングは、現在のMuleイベントと同じスレッドでログを書き込む（そのため書き込み失敗時にロールバックできる）。
    • 性能を維持しつつ重要な例外ログの損失を防ぐ ➡️ log4j2.xml で非同期ロガーと同期ロガーの混合構成（Mixed configuration）を使い、重要な例外のみ同期で記録する。
    • CloudHubログを無効化しSplunkのみに保存 ➡️ Runtime Managerでデフォルトログを無効化し、各アプリの log4j2.xml にSplunkアペンダーを定義する。
  • エージェント・JMX・アラート・監査ログ
    • Runtime Managerに接続せず閉域網で自動デプロイ ➡️ Runtime Manager Agent ＋ Agent REST API。
    • JMXエージェントで実行できる操作 ➡️ 「特定のlog4j2ログレベルをTRACEに動的変更する」。
    • Runtime Managerの標準アラート条件 ➡️ CPU使用率、メモリ消費量、イベントトラフィック閾値（※証明書期限やディスク容量は標準アラートにない）。
    • 過去1年間の操作履歴の抽出 ➡️ 監査ログは6年間保存されるため、Audit Log Query Platform API でフィルタ抽出する。

5.3 CI/CD自動化・テスト戦略・SLAパーセンタイル計算

  • API管理とCI/CDツールの役割分担
    • APIポリシー適用の事前準備：Exchangeに公開後、API Managerから「API Instance ID」を取得してAPI実装（Auto-discovery）に設定する。
    • Client ID Enforcement適用済みAPIのテスト前準備：Exchangeから対象環境のAPIインスタンスへ「アクセスをリクエスト（Request Access）」し、Client IDとSecretを取得する。
    • Anypoint CLI ＝ APIの作成・公開・デプロイ・管理のライフサイクル全体をスクリプトで自動化。
    • Mule Maven Plugin ＝ コンパイル、パッケージ化、単体テスト、デプロイ、統合テスト（※APIの公開や管理は不可）。
    • MUnit Maven Plugin ＝ MUnitテストの自動実行。
    • バイナリアーティファクトリポジトリ（Nexus等） ＝ ビルド成果物や全依存関係を共通の場所に保持。
  • テスト戦略（MUnit / 性能テスト）
    • 外部SOAPや本番DBを呼ばずにテスト ➡️ MUnitのMock を使用。
    • メインフローにエラー分岐がないのにMUnitカバレッジが80%止まり ➡️ 未通過の**エラーハンドラー（20%）**を通すため、エラーを発生させるMockテストを追加する。
    • ステージング環境のバックエンドにだけ厳しいレート制限がある場合の性能テスト ➡️ 本番のパフォーマンス特性をシミュレートするモックサービスを作成し、それに対して性能テストを実行する。
  • HTTPステータスコードとSLA計算
    • HTTP Requestで 3xx ＝ 外部APIによって別URLへリダイレクトされた。4xx ＝ 送信したリクエスト内容にクライアント起因のエラーがあると報告された。
    • 下流APIにタイムアウトを設定しないリスク ➡️ 上流（Upstream）APIのSLAを保証できなくなる。
    • パーセンタイルSLAの計算：上流APIの目標が「99%が800ms以内」なのに、1つ目の下流APIのSLAが「95%が1000ms以内（＝5%は1000ms超）」である場合、どんなタイムアウト値を設定しても99%成功かつ800ms以内は達成不可能。したがって 「目標SLAを満たすタイムアウト設定は存在しないため、下流APIと別のSLAを交渉するか代替APIを呼ぶ」 が正解。
0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?