How to prepare for MuleSoft Certified Developer Certification - Part III

 Are you preparing for MuleSoft Certified Developer Certification and looking for some guidelines and material about how to prepare then you have reached the right place. During preparing for MuleSoft Certified Developer Certification, I captured notes. I thought let me share everyone so that it will be beneficial to whoever preparing for the certification. This is the third part of the notes. You can visit the previous part if you have not visited yet here - How to prepare for MuleSoft Certified Developer Certification - Part II. You can visit the next part of the notes here -  How to prepare for MuleSoft Certified Developer Certification - Part IV. 

Item	Notes
Consuming web services	1. Modules are extension to the Mule runtime than we can use when building Mule Application e.g. HTTP, Database, Slack etc. 2. Connectors are modules that connect to an external server e.g. HTTP, Database, Salesforce 3. Connector support level Tier 1 : Mulesoft will isolate the problem and diagnose it Tier 2: Mulesoft will find a workaround Tier 3: Mulesoft will fix code 4. Connector Types Premium -> Tier 1-3, Fully tested, Updated APIs, Additional Cost Select -> Tier 1-3, Fully tested, Updated APIs Mulesoft Certified -> Tier 1 (Developer - T2/T3) Community -> Tier 1 5. If the connector is not available for RESTful web services then we can use HTTP connector and its Request operation 6. If the connector is not available in exchange for SOAP Web service the use Web Service Consumer connector. The response returned will be SOAP 7. WSDL file type is required to configure a Web Service Consumer to consume SOAP Web service. 8. Query parameters in the HTTP request operation can be sent in order to pass it to outbound REST request dynamically. 9. Design API in design center and publish it to Exchange to create a connector using REST connect
Controlling event flow	1. In order to route event synchronously we can use flow reference 2. In order to route event asynchronously we can use VM queue 3. Choice router can be used to route event based on conditional logic 4. First successful - routes sequentially until one successfully executed 5. Round Robin - one route executed, which one is selected by iterating through a list of maintained across execution 6. Scatter-gather - all routs executed concurrently (asynchronously). Results are combined into an object 7. If we use Scatter-gather flow control then all the object combined in the result need to be flattened using Transform Message component as flatten(payload..payload) 8. If validation the component is used and validation fails the rest of the flow components will not be executed and response is sent back to the client 9. Scatter-gather returns Mule event object or Mule event object within another object 10. Choice router finds the FIRST true condition and then distribute the event to ONE matched route
Handling errors	1. Error can be handled at                 a. Application level                 b. Flow level                 c. Processor level (by adding TRY scope) Note:    a. Subflow do not have error handling section    b. Mule Default handler is on error propagate 2. Messaging error occurs when an event is being processed and an error gets thrown.                 The normal flow execution stops                 The event is passed to first the processor in an error handler 3. Default error the handler will be used if                 No error is defined                 No valid error handler to handle an error 4. If an error occurs then error.description (String) and error.errorType (Object) gets generated 5. Error types are identified by namespace and an identifier HTTP(namespace):UNAUTHORIZED(identifier), HTTP:CONNECTIVITY 6. error type ANY is most general Parent 7. All error is either general or critical (FATAL, OVERLOAD) 8. Error handler scopes                 a. On Error Continue (HTTP listener returns SUCCESS)                 b. On Error Propagate (HTTP listener returns an error) 9. Application level error handlers get executed when there is no flow or processor level error handler available 10. If multiple error scopes are defined for the error handler then the first error scope whose condition evaluates to true is executed. If the error no matched the mule default error the handler will be executed and not application default 11. There are two ways to specify error conditions                 a. Set type to ANY (Default) or one or more at Error Scope                 b. adding Boolean dataweave expression at when conditions 12. If flow level error handlers present, the application-level error handler will be ignored 13. Error at processor level can be handled by adding TRY scope.                 a. On Error propagate                                 If transaction is being handled then it is rolled back.                 b. On Error continue                                 If transaction is being handled then it is committed 14. APIkit Error                 BAD_REQUEST, NOT_FOUND, METHOD_NOT_ALLOWEED, NOT_ACCEPTABLE, UNSUPPORTED_MEDIA_TYPE, NOT_IMPLEMENTED