# MCIA(MuleSoft Certified Integration Architect) Review
[TOC]

[](https://hackmd.io/OkSUHDLGQA6APZNv4srOkA)

## Initiating integration solutions on Anypoint Platform (1, 2, 3, 7)
### Summarize the fundamental value proposition of MuleSoft Catalyst and Catalyst Knowledge Hub
* C4E
* C4E's KPI
* ResponseTimeや稼働率など単一のメトリックをこえ、Application Networkが組織全体的にEnablementできているかがポイント
* e.g. The number of each business group's APIs that connect with C4E-documented APIs

### Differentiate between functional and non-functional requirements for integration solutions
* 機能要件(FR)
* 非機能要件(NFR)

### Select features of Anypoint Platform for designing and managing web and event-driven APIs
* Flow and Subflow
* Connectors
* HTTP (based on project Grizzly)
* Database
* File releated
* SaaS
* Salesforce
* Thru Manages File Transfer (Thru MFT)
* Custom (feat. Mule SDK)
* Scheduler
* Cloudhudでは1つのWorkerのみで実行、UTC時間に基づく
* Customer-hosted with clusterでは、Primary Nodeのみで実行
* Dataweave
* application/dw
* Performanceが低く、あくまでDebuggingやTesting用
* 必ずしもOOMが発生しないとは限らない
* Properties
* Read
* externalResources : 外部Entityを読み込む
* javaModule : Java module functionを読み込む
* onlyData : functionのようなものは扱わず、DataのみをHandling → Dataweave parser runs faster
* privileges : Accept a comma-separated list of privielges to use in the format such as 'Resources,Properties'
* Write
* bufferSize : size of the buffer writer
* deferred : Generates the output as a data stream
* ignoreSchema : ignore schema
* indent : String to use for indenting
* maxCollectionSize : ArrayやObjectで許容された最大のElementの数
* onlyData : functionのようなものは扱わず、DataのみをHandling → Dataweave parser runs faster
* Error Handler
* Router
* Choice
* Scatter-Gather
* Parallel (routerそのものはSync)
* Round Robin
* Synchronous
* First Successful
* Purpose : failover

#### ルーターエクササイズ
- 2 番目の API が、最初の API のレスポンスを必要とする (... HTTP Request 1 -> HTTP Request 2-> ...)
- A. **ルーターを使用しない**!
- A. vars (変数)に HTTP Request 1の結果を入れておくことで、payload を上書きしない (もしくは、 HTTP Request 2の結果を target variable に保存することで、HTTP Request 1のpayload を上書きしない)

- 各APIはそれぞれのレスポンス (注文、顧客) に依存しないが、結果を統合する必要がある
- A. **Scatter-Gather**

- 2 つの Address Validation (住所バリデーション) API エンドポイントで同一の機能を実行するが、そのうちの1つはフォールバックオプションになる
- A. **First Successful**

- リージョンに応じて Inventory (在庫) API の異なるリージョンエンドポイント(ANZ, Japan) を使用する必要がある
- A. **Choice**

- 各種保険会社からの Insurance Quote (保険の見積もり) API を呼び出し、結果を統合してソートする必要がある
- A. **Scatter-Gather** -> **Dataweave**

### Select deployment options of the Anypoint Platform control plane and runtime plane

* Control plane
* MuleSoft-hosted

* Runtime plane
* MuleSoft-hosted (Cloudhub)
* Automatic update, patch etc. supported by MuleSoft
* Customer-hosted　

* Mule RuntimeにRuntime Manager Agentが入っている　
* 顧客の方でDeployment process, Load balancing, Schedulingを管理する責任がある
* 可用性のためには、
* Clustering
* HZ(HazelCast)ベースの分散共有メモリーグリッド(IMDG)
* 

* Active-Active model for all nodes
* Runtimer serviceのOption別比較

| Service | Cloudhub 1.0 | Cloudhub 2.0 | Customer-hosted (w/ RTF) |
|-----------------|-----------------------------------------------------------------------|--------------|--------------------------------------------|
| Object Store | * Object Store Connector * Inmemory OS | TBU | * Inemory OS * File-based OS * HZ-based OS |
| Anypoint MQ | * Anypoint MQ Connector | TBU | * Anypoint MQ Connector |
| Property 保護 | * Runtime Managerユーザーから非表示にできる | TBU | * N/A |
| Access Security | * Mule Apps can access to CH service at any time * Served by MuleSoft | TBU | |

* デプロイオプション決定する時の考慮要素
* HA
* 自動的なFailOver
* OOTB(Out-of-the-box)の必須機能
* Object Store
* Sharedリソースのサポート
* Persistent Queue
* Scheduling
* Logging
* Dashboard
* Insight
* Alert
* Auto Scaling
* Anypoint Edge Security
* Tokenization

## Designing for the runtime plane technology architecture (3, 4, 13, 16)
### Analyze the mode of operation of a Mule runtime cluster that differentiates it from other deployment options
* Clustering Best Practice
* 可能な限り複数のStepで分ける
* Transactionを使う
* Transactionが使えない場合、ReliabilityPatternを適用
* 全てのClusterから確認できるようにDistributed Storeを使う
* Performance最適化のためにVMConnectorを極力利用する
* Doc : https://docs.mulesoft.com/mule-runtime/4.4/mule-high-availability-ha-clusters#cluster_fips

### Design integration solutions deployed to CloudHub to address specific requirements using CloudHub's network features
* SLB(Shared) vs DLB(Dedicated)
* Workerに関するあれこれ 

* SLB
* AWS ELB(Elastic Load Balancing)ベース
* DNSエントリーは、「CNAME」
* 80(http)/443(https) -> 8081(http)/8082(https) -> MuleApps' workers (Round Robin)
* 証明書はMuleSoftで管理
* DLB
* Anypoint VPCにデプロイされたMuleアプリケーションが対象
* CIDR 

* IPの割り当て 
* VPCの非公開範囲でPrivate Addressが2つ以上
* Public Addressも。（Aレコード）
* 任意の自社ドメインをCNAMEとして登録可能
* e.g. https://ranking.hellomule.com/daily/

* 公開用APIに加え、VPC内の非公開API用のDLBを作成することも可能
* すなわち、複数のDLBが生成可能
* 証明書は顧客が管理（CNAMEをカバーする）
* APIクライアントは、LB上の証明書だけを確認して、LB~MuleAppのところの証明書は特に気にしない。
* （非推奨アプローチ）LBを経由せずにMule Workerに直接アクセスする場合は、LB ~MuleAppの証明書を確認する。（Self-signed CRTの場合、クライアントはそれを受け入れられる設定が必要になる可能性がある。）

## サンプルアーキテクチャ

* Anypoint VPC(DLB)の使用シナリオ
* DLBとAPI実装の間の双方向認証
* カスタムドメインに関するHTTPS接続
* 外部からのリクエストを、API実装に紐づくためのMapping Rule

### Choose Mule runtime domains and domain-shared configuration only for those requirements that clearly benefit from their capabilities
* Domain project
* TBU

### Design Mule applications making effective use of the implications of the Mule 4 class loader isolation of Mule modules
* Class loader isolation
* 定義：各Connnectorが使っているJavaクラスをロードする際に、お互い見れない。
* 目的：アプリケーションの中で、複数のConnectorが使っているJava Libraryのバージョンが異なる可能性がある →　リソース衝突の恐れがあるのでそれを防ぐためにロードの空間を分離する。
* How to
* Application code : Refer to 'Artifact Filtering Class Loader'
* Extension code : Refer to 'Artifact Class Loader'
* Artifact Class Loader : Regular Java class loader pointing to the JAR files included in the extension. Load all files and classes of the extension.
* Artifact Filtering Class Loader : Wrapper created over the Artifact Class Loader. (uses decriptor named mule-artifact.json)
* MCIA sample 
* Docs
* https://docs.mulesoft.com/mule-runtime/4.4/about-classloading-isolation
* https://docs.mulesoft.com/mule-runtime/4.4/how-to-export-resources
* https://docs.mulesoft.com/mule-sdk/1.1/isolation#second-scenario-returning-two-instances-of-the-same-class-in-different-versions (directly related with the above sample quiz)
* Classloading is automatically filtered by package and not by class
*   

### Describe the characteristics and implications of the Mule 4 reactive event processing model
* Non blocking and Reactive event processing model
* Concurrency(同時性、並列性)
* Event-based
* Asynchronous
* Back-pressure
* 簡単に言って、Throttling。HTTPの場合同時リクエストの数が多すぎる場合、503を返すことなどをDefaultでするという意味。
* maxConcurrency属性で手動設定も可能
* Execution Engine
* Docs : https://docs.mulesoft.com/mule-runtime/4.4/execution-engine
* Mule event processors indicate to Mule whether they are CPU-intensive, CPU-light, or I/O-intensive operations.
* Processing type
* CPU-Light (Default makes something with Mule SDK)
* Quick ops (around 10ms), non-blocking IO like logger, HTTP request
* Blocking I/O
* blocks the calling thread like DB Select ops, SFTP read etc.
* CPU Intensive
* takes more 10ms. Should not perform any I/O activities like Transform message component
* Threading
* Proactor pattern
* Transaction : use only a thread
* Configuration
* Runtime level
* UBER (4.3~)
* DEDICATED (Legacy)
* Recommendation
* 何も変えないこと
* なんか変えたら必ずPerformance Testをすること
* App level
* poolStrategy can be adjustable BUT don't recommend to change it
* App level config doesn't override it of Runtime level just creating completely new set of thread pools

## Designing architecture using integration paradigms (2, 3, 4, 13)
### Create high-level integration architectures using API-led Connectivity
* 一番効率の良い方法
* CDM(Common Data Model)を使う
* Backend Systemが複数ならSAPIも複数
* Clientが多くても、EAPIを1つに絞ることも可能　→ その後RequestをCDMに変換して、共通のPAPIに転送
### Create high-level integration architectures using web APIs and HTTP
### Create high-level integration architectures using event-driven APIs and message brokers
### Design Mule applications and integration solutions using common messaging patterns and technologies

## Designing and developing Mule applications (2, 3, 4, 5, 10, 12, 13, 15)
### Select among available options for setting Mule application properties
* Doc : https://docs.mulesoft.com/mule-runtime/4.4/configuring-properties
* 種類 (優先順位順)
* Deployment properties
* System properties
* Environment properties
* Application properties (includes configuration properties, secure configuration properties, and other custom configuration properties)
* Global properties
* 上位のPropertyを参照することが可能
### Select and use fundamental features available to all Mule applications
TBU

### Design Mule applications using core routers available to all Mule applications
* Reference (For Each / Parallel For Each / Batch Job)
https://apisero.com/mulesoft-for-each-parallel-for-each-and-batch-processing-comparison/

* MCIA sample quiz 

### Describe the fundamental features of the Salesforce connector
* Salesforce Connector
* Support
* Salesforce Apex SOAP API
* Apex REST API
* Bulk API
* Metadata API
* Streaming API
* Limitation
* Chatter API / Tooling APIはサポートしていない

### Design Mule applications using common features of core connectors
* Sync (同期)
* Flow
* 単一イベントの処理は1つの専用スレッドで行われる
* Transaction scope (with Flow, Try etc.)
* Flow全体に適用される
* Async (非同期)
* 特徴
* Flowなど外部のError handler使えないため、Async scope + Try scopeという感じでエラーを処理
* 失敗してもMain flowには影響しない
* ResponseがあってもMain flowに提供されない
* Connectors
* JMS(Java Messaging Service)
* Docs : https://docs.mulesoft.com/jms-connector/1.8/
* Type

* 1:1 (using Queue)
* 順番に受信
* 1:many (using Topic)
* 順番の保証はできない
* Operation
* Publish
* Publish Consume
* Consume : Flowの任意で場所でMessageを受信
* Listen
* Exclusive queueとして設定可能
* とにかく誰かはメッセージを消費する
* Supports Reconnection Strategy
* Anypoint MQ
* Type 
* Standard queue
* FIFO queue
* Message exchange
* Lock and Ack
* Lock : 特定のConsumerから取得されている間、一定期間ロックされ、その間は他のConsumerからはInvisibleになる。
* 時間が経過したらTimeoutされ、他のConsumerから取得可能になる
* Dead Letter Queue (DLQ)
* DLQにメッセージを送る前に、RetryやMaxRetryの設定が可能
* 1~1000 (Default 10)
* VM
* Transient / Persistent
* Simplified queue service
* Message Balancingの単位
* Cluster : Nodes on a cluster
* Cloudhub : Workers on an app
* Application内の分散処理
* Domain Projectに基づいている場合のみ（つまりCustomer-hosted） App間でのメッセージ共有ができる
* HTTP Connectorは独自のThread poolを持っている (Grizzly)

### Select and use the available sources of metadata in the Transform Message component
* 利用可能なソース
* JSON
* XML
* Java
* CSV
* Excel
* RAMLデータ型のFragmentを使用し、ObjectまたはCSVのメタデータを定義することができる
* etc.
### Design Mule applications and integration solutions using a Common/Canonical Data Model
* 背景
* 重要なデータが全社的に互換性のないサイロでロックされた状態で保存されていることが多い
* Backend SystemとサポートしているMuleアプリケーションを変更から切り離す
* Pros and Cons
* 

### Correctly apply methods for validating data in Mule applications
* Invalid message validation
* Target
* Event Sourceに受信したデータがある場合
* HTTP Listener, On Table Row, JMS operations etc.
* 
* 方法
* Dataweave
* Module / Connector
* Validation（色々組み合わせることも可能）
* JSON / XML : スキーマ検証
* Java : 型の検証
* Choice Router

## Designing automated tests for Mule applications (6)
### Design unit test suites using MUnit and Studio's related features
* Scope
* Behavior
* Execution
* Validation
* How to execute
* **同一の**Mule RuntimeでテストとApplicationそのものを実行する
* MUnitを使ってIntegration Testをすることも
* MUnit Maven Plugin
### Identify test requirements and scenarios that are best addressed using - integration testing or performance testing
* Integration Test
* with external systems
* Performance Test
* Capacity, Response time, Scalability, Reliability

## Designing integration solutions to meet persistence requirements (4, 7, 8, 13)
* Clusterの場合、BatchJob以外は全てMemoryで管理
* Clusterなければ(or performance profile)、Diskの方が長く持つから、Diskで管理
* Batch Queueは、種類を問わずHazelCastを使用しない→全部がDiskに格納
* JDBC Storeは、Customer HostedのOSのだけのために使われる。(N, NP療法を持つのが印象的)
* Persistence Gateway(RTF)は、**ONLY FOR** Peristent ObjectStore。
* Batch QueueやVMとかと関係ない
* Batch Queueは全ての構成でpod/replicaのDiskを使用する。 HazelCastも使用しない。
* 酷悪がデータベースを提供する必要あり
* k8s secretを使用して、データベースの接続情報を保存
* 最大TTLは、Defaultで30日
* Clusterの場合、VM QueueはHazelCastの中に保存される。(Transient, Persistent問わず)
### Design Mule applications using VM queues and the Anypoint VM connector in all deployment options
* Concept
* FIFO
* at-least-once
* メッセージはSerializableでなければならない
* Domain Projectで定義された場合、同じDomain内のApplication間で共有可能
* 高度なキュー管理機能はない

* Use case
* Persistent Queueを有効にした複数のCloudhub Worker
* Cluster内の複数のNode
* RTF(with cluster)

* Deployment option
* Cloudhub
* Persistent Queueを使う場合、VMQueueは種類(Transient, Persistent)を問わずPersistent Queueを使う
* Worker間で共有される
* 保存時の暗号化を有効にすることが可能　
* maxOutstandingMessages属性を使って、キューのメッセージ数を制限可能
### Design Mule applications using Object Stores, the OS connector and OS services in all deployment options
* Object Store
* 複数のフロー呼び出し間でStateを保存するように設計
* Domain Projectで定義された場合、同じDomain内のApplication間で共有可能
* Transactionのサポートなし
* Object Store v2
* Persistentの場合に使われる
* TLS通信
* FIPS140-2準拠の暗号化
* Application削除したら、OSv2のデータも削除される
* Transactionのサポートなし

* OSv2 REST API
* Store / Retrive with Key-value pair

### Design Mule applications and integration solutions using stateful components that may be configured with an Object Store
* Batch Job
* Concept
* メッセージを個々のレコードに分割し、Persistent Queueに格納
* 大規模なデータセットを確実に処理
* クラッシュ時の処理状態の回復
* 履歴ファイルがDiskに保存される
* Defaultは7日間
* 処理が終わったら、個々のレコードの状態は失われる
* Deployment options
* Cloudhub
* Performanceに影響があるため、Batch処理にPersistent Queueを使うことは推奨されていない
* Watermark

## Designing integration solutions to meet reliability requirements (4, 11, 12, 13)

* Reliability Patternを適用するときの考慮事項(Consideration)
* It has performance implications
* It requires using an XA transaction to bridge message sources when multiple managed resources need to be enlisted within the same transaction

### Select alternatives to traditional transactions (local or XA) where appropriate and beneficial
* Transactionの代わり
* JMS Acknowledgement
* Saga Pattern
* Commit and Rollbackではなく、Do and Undo
* Choreography パターン
* 複数のリソースをロックすることでOverhead発生可能性がある。
* Orchestration パターン
* CAP原理による
* Consistency, Availability, Partition Tolerance

### Recognize the purpose and characteristics of Until Successful scope, reconnection strategies, and redelivery policies
* 信頼性(Reliability)達成のための機能
* Until Successful Scope
* Flagや他の必要なエラー情報を設定するためには、On Error Continueを使用して、スコープから抜け出して使うのが一般的。
* Reconnection
* Redelivery policy
* On New Messageに対して使用
* Exception scope (MULE:REDELIVERY_EXHAUSTED)
* Transaction, Error handling, First Successful Router

### Differentiate between disaster recovery and high availability and the basic approaches to achieving either in all deployment options
* Disaster Recovery (DR)
* Recovery Time Object (RTO)
* How quickly
* Recovery Point Object (RPO)
* Zero data loss
* High Availability (HA)
* HA for hosting options
* Cloudhub
* Docs
* https://docs.mulesoft.com/cloudhub-1/cloudhub-hadr
* Deployment model
* Default 
* Suggested(similar with k8s pod behavior) 
* Keep Integrations Stateless
* 状態保持のためにはなるべく外部リソース(DB, MQ etc.)を使い、内部的な依存性や複雑性を持たない。
* 各Nodeの状態を独立させる。

* Customer-hosted
* HA Options
* Cold Standby
* 環境設定はOK＋全く動いてない

* Warm Standby
* 環境設定はOK＋動いてない＋OSは起動している
* 必要時RuntimeだけOn

* Hot Standby - Active-Passive
* 動いてる＋リクエストは受けてない
* Active-Active
* 動いてる＋リクエスト受けている

* Docs
* https://docs.mulesoft.com/mule-runtime/4.4/hadr-guide
* https://docs.mulesoft.com/mule-runtime/4.4/mule-high-availability-ha-clusters
* Clustering　 

* Sharing workload across multiple nodes 
* Automatic load balancing (with VM etc.) 

* Automatic coordination of access to resources (e.g. File, Database, FTP etc.)
* Able to set alerts for connecting / disconnecting
* Server Groupと比べ、以下のところでメリットがある。
* File based connectors
* Fileの重複処理が発生しうる
* Multicast connectors
* メッセージの重複処理が発生しうる
* JMS topics
* メッセージの重複処理が発生しうる
* JMS request-reply/request-response
* 関係のない応答をもらえる
* Idempotent Redelivery Policy
* メッセージの重複処理が発生しうる
* Salesforce streaming API
* Single consumerのみを許容しているので処理が失敗する
* Works on Primary Node
* Scheduler source
* Any other sources with ```primaryNodeOnly```
* Connectors supporting clustering
* Socket-based : TCP, UDP, HTTP(S)
* Listener-based : JMS, VM
* Resource-based : File, FTP, SFTP, JDBC etc.
* TCPリクエストを処理する場合は、Load Balancerが必要(Apache, Nginx etc.)
* Node間の通信は暗号化可能
* ```mule.cluster.network.encryption.key``` in ```wrapper.conf```
* Profileの設定 ```mule.cluster.storeprofile=performance

                    * performance store
                        - 注意
                        FileのようにSingle Consumerのみを許容するConnectorとClustering可能なConnector(e.g. JMS, Multicasting etc.)を同時に使う場合、結局Node1つでだけしか処理できないので、performance store設定するとBottleneckになる　→ Off
                        - ObjectStoreは、他のNodeへの複製なしで実装
                        - Performance store使ったら、HazelCastは使わない ![](https://i.imgur.com/BnKA3m8.png)

                    * reliable store
                        - Runtime clusterそのものに設定するか、各MuleAppごとに設定できる![](https://i.imgur.com/ruKEQTK.png)
n
                    * App-levelの設定がConf-levelの設定をOverrideする
                    * 新しいNodeを追加するとき
                        - External monitoring toolやlog aggregatorがある場合は新しいNodeを認識させるための設定が必要
                * Clustering Best Practice
                  - Transaction as possible (Use transactional connectors)
                  - Reliable pattern with VM, JMS
                  - Use distributed stores so that the stores are available to an entire cluster
                  - Use VM connector to get optimal performance
                    - Use JMS if data needs to be saved after the entire cluster exists

### Design Mule applications and integration solutions using local and XA transactions for all Mule connectors that support them
* Transaction
    * 前提：ConnectorがTransactionをサポートしている必要がある。
    * Local
    * XA
* Transactionを開始方法
    * ALWAYS_JOIN
    * TBU

* Transaction Log
    * $MULE_HOME/.mule/<appname>/queue-tx-logに保存
    * Defaultでは最大５万件のレコードが含まれる。
    * Performanceを高めるために、TX Logsize(maxQueueTransactionFilesSize)をチューニングすることも可能
    * BTM, XA, Localのログが入る（State保存）

* TransactionをサポートしているConnector
    * Database
    * JMS
        * Publish, Consume
    * VM
        * Publish, Consume

* TXへの参加
![](https://i.imgur.com/Llbtgnp.png)

* トランザクションの終了
    * Commit
        * Flow
        * Try scope
        * On Error Continue
    * Rollback
        * Transaction scopeでエラーが発生し、On Error Continueで処理できない場合
        * On Error Propagate
        * Raise Error
* Rollbackに関して
    * XAの範囲を超えるXAが必要な場合（e.g. 複数Appが同じデータベースをUpdateしている時のTransaction）
        * 方法
            * Impl local transaction in each API
            * + Coordinate between the API impl using a Saga pattern
            * + Apply various compensating actions depending on where a failure occurs

## Designing integration solutions to meet performance requirements (4, 8, 13, 14)
### Design Mule applications and integration solutions to meet performance and capacity goals
* Sample quiz
![](https://i.imgur.com/9Va0diW.png)
-> 150(app#) * 3(env#) * 2(worker#) * **2(for zero downtime)**

### Design Mule applications using available streaming features in Mule
* Streaming
    * Docs : https://docs.mulesoft.com/mule-runtime/4.4/streaming-about
    * Non-Repeatable Stream
    * Repeatable Streams : Read steam more than once, Have concurrent access
        * Streaming Object (When streaming objects, the in-memory buffer size is measured in instance counts.)
            * Repeatable File Store (Iterable)
                * 特定のInstanceの数分だけのMemoryをDefaultとして設定。数分のBufferSizeを超えたら、Diskに格納
                * The more objects you save in-memory, the better performance you get from avoiding writes to disk.
                * ```<ee:repeatable-file-store-iterable inMemoryObjects="100"/>```
            * Repeatable In-Memory (Iterable)
                * 特定のInstanceの数分だけのMemoryをDefaultとして設定。数分のBufferSizeを超えたら、増加分のBufferSizeを追加。Maxを超えたら失敗。

* Streaming Strategy
* Target
* File connector
* FTP connector
* Database connector
* HTTP connector
* Sockets connector
* SalesForce connector
* File-stored repeatable stream (Default of EE)
* Only available in Mule Enterprise Edition (Mule EE)
* 最初は512KBのMemoryに保存、それを超えたらDisk上にTemp Fileを作成
* Bufferは```inMemorySize```, ```bufferUnit```で調整可能
* Bufferが小さい　→ Memoryの消費が少ない
* Bufferが大きい　→ Diskにかく回数を減らすことでPerformance向上にもなるが、同時性的には弱くなる。
* In-memory repeatable stream (Default of Community edition)
* 最初は512KBのMemoryに保存、それを超えたら追加分のMemoryを増やす。Maxを超えたらFailする。

<file:read path="exampleFile.json">
  <repeatable-in-memory-stream
    initialBufferSize="512"
    bufferSizeIncrement="256"
    maxInMemorySize="2000"
    bufferUnit="KB"/>
 </file:read>

* MCIA Sample quiz

### Design Mule applications to process large sequences/streams of messages
* Serialization API
* Docs : https://docs.mulesoft.com/mule-runtime/4.4/configure-custom-serializers
* API allows an InputStream as an input source
* API passes an OutputStream when serializing and streaming
* thread-safe
* class-loader コントロール可能
* Customization可能

## Designing integration solutions to meet security requirements (9, 15, 16)
### Design secure access to the Anypoint Platform control plane and APIs
* Access to platform
* Organization
* Client ID & Secret
* Organization Owner
* 組織で最初に登録するユーザー（Super user）
* Ownerは、組織管理者(Organization Administrator)の権限を継承し、組織と子Business Groupのあらゆる権限を持つ
* Business Group
* Client ID & Secret
* Environments定義可能
* そのBusiness Groupと子Business Groupに対する完全な管理者権限をもつ所有者(owner)が存在する
* Parent Business Groupはもちろん対象外
* Teams
* ユーザーをグループ化し、権限の管理やアセットの共有を容易にする
* ID ProviderのGroupをTeamsにマッピング可能
* IdP
* Anypoint Platformと同期はしない (古いAccess Tokenを使うことになる可能性があるという意味)
* 同期させるには、間にMuleAppを開発して挟む必要がある　→ 追加作業が必要
* e.g. MuleApp(Client) -> MuleApp(仲介用) -> IdP
* サポート
* Identity(User) management
* SAML, OIDC
* Client management
* OAuth
* IdPを繋げる前からあったApplicationに対しては、IdPを使いたいならRecreationが必要
* 注意
* Client Managementから削除すると、既存の依存性をもつAPIやアセット、環境が影響される。事前に別のIdPに対する移行計画を立てるべき

* Access to APIs
* Connected App
* OAuth2.0 / OIDC token with client_id and client_secret
* 権限を持つユーザーのような役割をする
* Grant typeの設定も可能
* Authorization code
* Password
* JWT Bearer etc.

### Design secure edge access using Anypoint Security
* Anypoint Security 
* RTFのSolution
* RTFのLBの一環として、MuleRuntimeの外にデプロイするStandalone製品
* APIManagerで定義したPolicyより先に適用
* LBと同じLayerになるので、多数のAPI Instanceに適用可能
* Service Virtualization
* Connection Security and Certificate Management
* Content Security
* Quality of Service
* Application Level(DoS, Denial of Service)
* Web Application Firewall
* Tokenization Service 

### Analyze and counteract potential security vulnerabilities of Mule applications
* Security Risk
* Injection
* 種類
* DB operation including Script, DDL execution
* XPath extract
* Parse template
* HTTP header
* Risk hedge
* Validation moduleやCoding
* bind変数を仕様し、SQLクエリ内での文字列操作を防ぐ
* 動的クエリを避ける
* Scheme Validation

* 認証およびSessio管理の不備
* 種類
* User Credentialが保護されていない
* 暗号化なし
* OAuth Contextがログアウトしていても続く
* Risk hedge
* Hashingや暗号化して認証情報を保存
* Customer-hostedではSecure Property file使う
* Cloudhubではhidden propertyを使用する
* HTTPSを使う
* Sessionはすぐに無効化する
* Security設定ミス
* 種類
* APIKit Consoleがいらないのに有効化
* Connectorの設定不備
* Error処理
* 使われないEvent SourceやConnector（不要な入口）
* Risk hedge
* Architectちゃんと設計
* 定期的にSecurity Scan
* 設定ちゃんとする
* 機密データの漏洩
* 種類
* Propertyの値が全部見える
* ObjectStoreなどがPrivateになっていない
* 証明書を使っていない
* Risk hedge
* Secure property
* 暗号化、Hashing、Masking
* 権限設定などでアクセス保護
* 脆弱性のあるコンポーネントの使用
* 種類
* 古いTLS
* Custom Library
* Risk hedge
* 静的分析
* 最新のTLS
* 承認済みのLibraryだけ使う

* PropertyのSecurity確保
* Secure Property Configを使うことで暗号化が可能
* Secure Property File1つごとに1つのConfig 
* secure:: prefixを使ってアクセス 
* Cloudhubでpropertyを隠すには、
* mule-artifact.jsonのsecurePropertiesに追加

* Mule Cryptographyモジュールを使って、通信の暗号化も可能
* Java cryptography extension (JCE)
* Pretty good privacy (PGP)
* XML
* Dataweave 


* TLS
* Keystore : 自分のもの
* Truststore：相手のもの
* JMS標準ではTLS接続を指定していない
* JMS ProviderはTLSをサポートし、Client LibraryでTLS接続Factoryを提供する必要がある
* 双方向 
* 証明書は外部化して管理することが望ましい
* <MULE_HOME>/conf/wrapper.confのclasspathに証明書Folderを追加 ```wrapper.java.classpath.3=%CERT_DIRECTORY%```

### Recognize the audit logging capabilities of Anypoint Platform
* Audit Log
* ログイン、Business Groupの作成、環境の作成など、Platform内のユーザーの動きをログに記録
* Control Plane上での全ての変更をログに記録
* 組織のOwnerは、全ての監査ログにアクセス可能
* 特定のBusiess GroupのAudit Logは、そのBusiness GroupのAudit Log Viewer権限が必要
* ６年間保存
* Audit Logging Query APIをサポート

## Applying DevOps practices and operating integration solutions (9, 10)
* Maven repository
* Public
* Private (Enterprise)
* 顧客は自分達の専用Repoを構築することも可能（Enterprise Licenseが必要）
* Doc : https://docs.mulesoft.com/mule-runtime/4.4/maven-reference

### Create the high-level design of CI/CD pipelines for Mule applications using MuleSoft-provided Maven plugins
* Mule maven plugin
* compile, test, package(create a jar), install(local repo), deploy(remote repo)
* Domain, Applicationに対応
* Deploy to
* Cloudhub 1.0/2.0
* RTF
* Server / Cluster using Runtime Manager REST API
* all Mule instances reside in one address space using Runtime Manager Agent (AgentがインストールされたリモートのホストからDeploy)
* Standalone
* Doc : https://docs.mulesoft.com/mule-runtime/4.4/mmp-concept
* MUnit maven plugin
* test

### Identify the features and characteristics for automating interactions with Anypoint Platform
* Anypoint CLI
* 内部的にはAnypoint Platform APIをCall
* Anypoint Platform API
* using OAuth2
* env idまたはorg idを必要に応じて設定
* Cloudhub API, Access Management API, API Manager API etc.

### Design the logging configurations and options of Mule applications in all deployment options
* Logger
* Default : INFO
* DEBUGまたはTRACEレベルのログは無視
* Deployment options
* Cloudhub 

* Customer-hosted 
* Sync and Async
* Sync
* for ERORR/CRITICAL errors
* Async (default as INFO level)
* Crash発生時、ログが消えることあり
* Runtime Managerでは再デプロイせずにLog Levelを無効化できる
* Mapped Diagnostic Context (MDC)
* 現在のログにより多くのコンテキストや情報を提供することで、ログを充実させ、トラッキングを改善する
* 条件
* Mule Tracingモジュールのインストール
* log4j2.xmlでPatternLayoutをMDCに変更 

* Correlation IDを使って、ログメッセージのトレースや異なるログエントリと特定の実行を関連づけることが可能
* 通常ソースメッセージから取得
* log4j2の基本設定により、ログに一緒に記録される 

* Custom Log
* Cloudhub
* Default : Mule Appのlog4j2.xmlを自分のものに置き換える
* サポートを経由し、Default Appenderを無効化・Mule Appで用意したCustom Log4j2を設定することも可能 (設定ミスには自分で責任取らないと)
* App log : 他のAppenderにExport可能
* System log : log4j2.xmlの対象外なので、他のAppenderにExport不可
* Cloudhub log4j appenderを使わない場合、Mule AppのログはRuntime Managerには表示されなくなり、ダウンロードもできなくなる。
* Custom Log AppenderにCloudhubのLog Appenderを組み込むことが可能 

* Cloudhubロギングサービスに書き込むカスタムlog4j Appender(CLOUDHUB)とローカルファイルに書き込むAppender(FILE)を指定する
* さまざまなログカテゴリーにDefaultのレベルを指定 
* Runtime ManagerからOverride可能
* Customer-hosted 

### Identify the features and characteristics of Anypoint Monitoring in all deployment options

* Custom mertics (only for Titanium) 
* 使いすぎると、Performance低下
* Functional Monitoring
* 外部のAPIも監視可能
* Public
* Max 5 monitors
* Execution / 15min (other than Titanium), Cron (Titanium)
* Private
* can monitor VPC
* use 0.2 vCore
* Execution / 5min (other than Titanium), Cron (Titanium)
* NewRelic, Slack, EMailなどで通知可能
* Supports BAT(Blackbox Automated Testing) CLI
* based on Dataweave expression
* can be a job on CICD pipeline