TOGAF Certification Series 2: Foundations Core Concepts

Chapter 3: Core Concepts

  • What are the ADM phase names and the purpose of each phase?


  • The Preliminary Phase describes the preparation and initiation activities required to create an Architecture Capability, including the customization of the TOGAF framework, and the definition of Architecture Principles.
  • Phase A: Architecture Vision describes the initial phase of an Architecture Development Cycle. It includes information about defining the scope, identifying the stakeholders, creating the Architecture Vision, and obtaining approvals.
  • Phase B: Business Architecture describes the development of a Business Architecture to support an agreed Architecture Vision.
  • Phase C: Information Systems Architectures describes the development of Information Systems Architectures for an architecture project, including the development of Data and Application Architectures.
  • Phase D: Technology Architecture describes the development of the Technology Architecture for an architecture project.
  • Phase E: Opportunities and Solutions describes the process of identifying major implementation projects and grouping them into work packages that deliver the Target Architecture defined in the previous phases.
  • Phase F: Migration Planning describes the development of a detailed Implementation and Migration Plan that addresses how to move from the Baseline to the Target Architecture.
  • Phase G: Implementation Governance provides an architectural oversight of the implementation.
  • Phase H: Architecture Change Management establishes procedures for managing change to the new architecture.
  • Requirements Management examines the process of managing architecture requirements throughout the ADM.
  • What are deliverables, artifacts, and building blocks?


  • What is the Enterprise Continuum?

The Enterprise Continuum is a view of the Architecture Repository that provides methods for classifying architecture and solution artifacts as they evolve from generic Foundation Architectures to Organization-Specific Architectures. The Enterprise Continuum comprises two complementary concepts: the Architecture Continuum and the Solutions Continuum.

The Enterprise Continuum and the Architecture Repository The Enterprise Continuum provides a view of the Architecture Repository that shows the evolution of these related architectures from generic to specific, from abstract to concrete, and from logical to physical. [Source: TOGAF 9 Part V: Enterprise Continuum and Tools]

  • What is the Architecture Repository?

Architecture Repository is used to store different classes of architectural output at different levels of abstraction

The major components within an Architecture Repository are as follows:

  • The Architecture Metamodel describes the organizationally tailored application of an architecture framework, including a metamodel for architecture content.
  • The Architecture Capability defines the parameters, structures, and processes that support governance of the Architecture Repository.
  • The Architecture Landscape shows an architectural view of the building blocks that are in use within the organization today (e.g., a list of the live applications). The landscape is likely to exist at multiple levels of abstraction to suit different architecture objectives
  • The Standards Information Base (SIB) captures the standards with which new architectures must comply, which may include industry standards, selected products and services from suppliers, or shared services already deployed within the organization.
  • The Reference Library provides guidelines, templates, patterns, and other forms of reference material that can be leveraged to accelerate the creation of new architectures for the enterprise.
  • The Governance Log provides a record of governance activity across the enterprise. abstraction to suit different architecture objectives
  • How to establish and operate an enterprise architecture capability?



    The benefits of Architecture Governance include:

  • Increased transparency of accountability, and informed delegation of authority
  • Controlled risk management
  • Protection of the existing asset base through maximizing re-use of existing architectural components
  • Proactive control, monitoring, and management mechanisms
  • Process, concept, and component re-use across all organizational business units
  • Value creation through monitoring, measuring, evaluation, and feedback
  • Increased visibility supporting internal processes and external parties’ requirements; in particular, increased visibility of decision-making at lower levels ensures oversight at an appropriate level within the enterprise of decisions that may have far-reaching strategic consequences for the organization
  • Greater shareholder value; in particular, enterprise architecture increasingly represents the core intellectual property of the enterprise – studies have demonstrated a correlation between increased shareholder value and well-governed enterprises
  • Integrates with existing processes and methodologies and complements functionality by adding control capabilities
  • How to use the TOGAF framework with other frameworks?

Why is the TOGAF standard becoming so popular in the industry? One key reason is that architects can use the TOGAF ADM in conjunction with any of the popular frameworks. The TOGAF ADM is framework-agnostic and helps IT architects fill in the framework they might already have in use.

Chapter 4: Key Terminology

  • Architecture: Architecture has two meanings depending upon its contextual usage:
    • A formal description of a system, or a detailed plan of the system at component level to guide its implementation
    • The structure of components, their inter-relationships, and the principles and guidelines governing their design and evolution over time.
  • Architecture Principles: A qualitative statement of intent that should be met by the architecture. Has at least a supporting rationale and a measure of importance.
  • Architecture Vision: A succinct description of the Target Architecture that describes its business value and the changes to the enterprise that will result from its successful deployment. It serves as an aspirational vision and a boundary for detailed architecture development.
  • Baseline: A specification that has been formally reviewed and agreed upon, that thereafter serves as the basis for further development or change and that can be changed only through formal change control procedures or a type of procedure such as configuration management.
Advertisements

TOGAF Certification Series 1: Foundations Introduction

Chapter 1 Introduction:

  • Why is TOGAF certification important? The existence of a certification program for the TOGAF standard provides a strong incentive for organizations to standardize on the TOGAF standard as the open method for enterprise architecture, and so avoid lock-in to proprietary methods. It is an important step in making enterprise architecture a well-recognized discipline, and in introducing rigor into the procurement of tools and services for enterprise architecture.
  • The purpose of certification to TOGAF 9 Level 1, known as TOGAF 9 Foundation, is to provide validation that the candidate has gained an acceptable level of knowledge of the terminology, structure, and basic concepts of TOGAF 9, and understands the core principles of enterprise architecture and the TOGAF standard
  • Individuals certified at this level will have demonstrated their understanding of:
    • The basic concepts of enterprise architecture and the TOGAF standard
    • The core concepts of TOGAF 9
    • The key terminology of TOGAF 9 
    • The ADM cycle and the objectives of each phase, and how to adapt and scope the ADM
    • The concept of the Enterprise Continuum; its purpose, and its constituent parts
    • How each of the ADM phases contributes to the success of enterprise architecture
    • The ADM guidelines and techniques
    • How Architecture Governance contributes to the Architecture Development Cycle
    • The concepts of views and viewpoints and their role in communicating with stakeholders
    • The concept of building blocks
    • The key deliverables of the ADM cycle
    • The TOGAF reference models
    • The TOGAF certification program
  • What is the relationship between TOGAF 9 Foundation and TOGAF 9 Certified? The learning outcomes for TOGAF 9 Foundation are a subset of those for TOGAF 9 Certified. Candidates are able to choose whether they wish to become certified in a stepwise manner by starting with TOGAF 9 Foundation and then at a later date TOGAF 9 Certified, or alternately to go direct to TOGAF 9 Certified by taking the combined examination

Chapter 2 Basic Concepts:

  • What is the TOGAF Standard? The TOGAF standard is an architecture framework. The TOGAF standard is a tool for assisting in the acceptance, production, use, and maintenance of enterprise architectures. It is based on an iterative process model supported by best practices and a re-usable set of existing architectural assets.
  • Structure of the TOGAF Document:
    • Part I: Introduction This part provides a high-level introduction to the key concepts of enterprise architecture and, in particular, to the TOGAF approach. It contains the definitions of terms used throughout the TOGAF standard and release notes detailing the changes between this version and the previous version of the TOGAF standard.
    • Part II: Architecture Development Method (ADM) This part is the core of the TOGAF standard. It describes the TOGAF Architecture Development Method (ADM) – a step-by-step approach to developing an enterprise architecture.
    • Part III: ADM Guidelines and Techniques This part contains a collection of guidelines and techniques available for use in applying the ADM.
    • Part IV: Architecture Content Framework This part describes the TOGAF content framework, including a structured metamodel for architectural artifacts, the use of re-usable Architecture Building Blocks (ABBs), and an overview of typical architecture deliverables.
    • Part V: Enterprise Continuum and Tools: This part discusses appropriate taxonomies and tools to categorize and store the outputs of architecture activity within an enterprise.
    • Part VI: TOGAF Reference Models: This part provides two architectural reference models, namely the TOGAF Technical Reference Model (TRM), and the Integrated Information Infrastructure Reference Model (III-RM).
    • Part VII: Architecture Capability Framework: This part discusses the organization, processes, skills, roles, and responsibilities required to establish and operate an architecture practice within an enterprise.
  • What is an Enterprise? An “enterprise” is any collection of organizations that has a common set of goals. For example, an enterprise could be a government agency, a whole corporation, a division of a corporation, a single department, or a chain of geographically distant organizations linked together by common ownership. The term “enterprise” in the context of “enterprise architecture” can be used to denote both an entire enterprise, encompassing all of its information systems, and a specific domain within the enterprise. An extended enterprise frequently includes partners, suppliers, and customers. If the goal is to integrate an extended enterprise, then the enterprise comprises the partners, suppliers, and customers, as well as internal business units. For example, an organization with an online store that uses an external fulfillment house for dispatching orders would extend its definition of the enterprise in that system to include the fulfillment house.
  • What is Architecture in the Context of the TOGAF Standard? Architecture has two meanings depending upon the context:
    • 1. A formal description of a system, or a detailed plan of the system at a component level to guide its implementation \
    • 2. The structure of components, their inter-relationships, and the principles and guidelines governing their design and evolution over time
  • Enterprise architecture is:
    • 1. The organizing logic for business processes and IT infrastructure reflecting the integration and standardization requirements of the firm’s operating model.
    • 2. A conceptual blueprint that defines the structure and operation of an organization. The intent of an enterprise architecture is to determine how an organization can most effectively achieve its current and future objectives.
  • Why do I Need Enterprise Architecture? The purpose of enterprise architecture is to optimize across the enterprise the often fragmented legacy of processes (both manual and automated) into an integrated environment that is responsive to change and supportive of the delivery of the business strategy. Effective management and exploitation of information through IT is a key factor to business success, and an indispensable means to achieving competitive advantage. An enterprise architecture addresses this need, by providing a strategic context for the evolution of the IT system in response to the constantly changing needs of the business environment. Ultimately, the benefits of enterprise architecture derive from the better planning, earlier visibility, and more informed designs that result when it is introduced.
  • What is an Architecture Framework? An architecture framework is a foundational structure, or set of structures, that can be used for developing a broad range of different architectures. It should describe a method for designing a target state of the enterprise in terms of a set of building blocks, and for showing how the building blocks fit together. It should contain a set of tools and provide a common vocabulary. It should also include a list of recommended standards and compliant products that can be used to implement the building blocks. Using an architecture framework will speed up and simplify architecture development, ensure more complete coverage of the designed solution, and make certain that the architecture selected allows for future growth in response to the needs of the business.
  • Why is the TOGAF Standard Suitable as a Framework for Enterprise Architecture? Using the TOGAF standard results in enterprise architecture that is consistent, reflects the needs of stakeholders, employs best practice, and gives due consideration both to current requirements and to the perceived future needs of the business.
  • What are the Different Architecture Domains that the TOGAF Standard deals with?
    • Business Architecture: The business strategy, governance, organization, and key business processes.
    • Data Architecture: The structure of an organization’s logical and physical data assets and data management resources.
    • Application Architecture: A blueprint for the individual application systems to be deployed, their interactions, and their relationships to the core business processes of the organization.
    • Technology Architecture: The software and hardware capabilities that are required to support the deployment of business, data, and application services. This includes IT infrastructure, middleware, networks, communications, processing, and standards.
  • Definition of “Capability”: An ability that an organization, person, or system possesses. Capabilities are typically expressed in general and high-level terms and typically require a combination of organization, people, processes, and technology to achieve. For example, marketing, customer contact, or outbound telemarketing.
    • An enterprise architecture capability (or architecture capability) in the context of the TOGAF standard, is the ability for an organization to effectively undertake the activities of an enterprise architecture practice.
  • What does the TOGAF Standard Contain?
  • TOGAF Reference Models
    • TOGAF Foundation Architecture Technical Reference Model: The TOGAF Technical Reference Model is an architecture of generic services and functions that provides a foundation on which specific architectures and Architecture Building Blocks (ABBs) can be built.
    • Integrated Information Infrastructure Reference Model (III-RM) : The Integrated Information Infrastructure Reference Model (III-RM) is based on the TOGAF Foundation Architecture, and is specifically aimed at helping the design of architectures that enable and support the vision of Boundaryless Information Flow.

MuleSoft: Salesforce Synchronization with Retry Sample

In addition to MuleSoft connection Retry, this pattern adds the retry of rejected or failed records by the target system validation, in case another retry would succeed

Scenario

In a recent project I was working on, I needed to keep Salesforce objects updates synchronized with Siebel. The basic integration scenario is shown in Figure 1.

Figure 1: Integration Scenario

There is one complication though, sometimes Siebel will reject updates or new records as validations fails due to missing data or racing conditions with other data records. Rather than letting records fail and logging errors for support or the user to resubmit, a retry approach after a period of time could remedy most of the errors. As depicted in figure 2, the logic for the synch is as follows:

  1. The synchronization job is schedule to run every 10 minutes.
  2. Fetch the last datetime the synch had run (in case the synch job was stopped for any reason such as maintenance).
  3. Fetch all modified or created accounts IDs from Salesforce since the last run
  4. Process Accounts
    1. Fetch the Account Objects for the records ID from steps 3
    2. Do the necessary conversions to Siebel format and send the updates to Siebel
    3. Send the Siebel IDs for accepted records to Salesforce
    4. For records that got rejected by Siebel, keep track of the record IDs and store them in MuleSoft Object Store with the number of retries.
  5. If there are Stored Rejected Record IDs from a previous run in MuleSoft Object Sore
    1. Fetch the record ID from Object Store
    2. Execute Process Accounts step 4
    3. If the number of retries exceeds 3 times log the rejection and create a ServiceNow ticker so support can track and resolve the issue

Figure 2: Synchronization with Capturing errors and Retry

The Sample

In the sample code found at my GitHub (https://github.com/RefaatM/MuleSoft_SyncWithRetry), I am simulating Siebel with a MySQL DB. The implementation will synchronize the Salesforce Account changes with a table in MySQL DB. The next few sections, walks through the code details

Project Structure

When you open the sample code in AnyPoint Studio, you will find the project code consisting of:

  1. Src\main\mule which contains the 4 workflows
  2. Src\main\java which contains 1 java helper class
  3. Src\main\resources which contains the configurations config.yaml

The other packages are the standard packages of any MuleSoft project. The 4 Workflows, 1 Java class and config.yaml implement the solutions.

Figure 3: Project Structure

General Workflow and Global Configuration

Figure 4: General Workflow

Following the MuleSoft best practices the Global workflow is where you will find the Global Exception Handler in this sample it just logs the error (figure 4) and the global configuration to use a config file for the different environments and the connections to Salesforce and MySQL DB (figure 5).

Figure 5: Global Configuration

Figure 6 shows that the Default Error Hander is set to the “General Error Handler” in the General Workflow. For a refresher on MuleSoft Exception Handling see MuleSoft: Understanding Exception Handling/

Figure 6: Global Error handler Configuration

Figure 7 Shows the setting of config.yaml as the source for the configuration information. It is important not to hard code any environment or properties.

Figure 7: Configuration properties source file

The listing below shows the contents of the config.yaml . All sensitive information is masked with * to run the sample you will have to enter the proper information for your environment.

sfdc:


username: “**************”


password: “***********”


token: “*****”

db:


host: “localhost”


port: “3306”


user: “root”


password: “****”


database: “synchsample”

Figure 8 shows the configuration of the Salesforce connection with parametrized information to be retrieved from config.yaml

Figure 8: Salesforce configuration

Figure 9 shows the configuration of the MySQL DB connection with parametrized information to be retrieved from config.yaml

Figure 9: MySQL Connection configuration

MainFlow

Figure 10: MainFlow

The mainflow is triggered by the scheduler the logic is :

  1. Log the start time
  2. Call the Get Duration subflow
  3. Query Sales force for update accounts
  4. Convert the result to a list of IDs to query
  5. Call Record Processing subflow
  6. Log the operation is finished
  7. In case of any error just log it.

CallRecordsProcessing Workflow

Figure 11: CallRecordProcessing Subworkflow

  1. Check if the list of record IDs is empty
    1. Not Empty: call Process Records
    2. Empty: log no modified records found

GetDuration Subworkflow

Figure 12: GetDuration Subworkflow

  1. Check if Object store contains saved lastTimeRun
  2. Contains LastTimeRun:
    1. Fetch the lastTime
    2. Call Helper Java method to get the duration
  3. Does not contain LastTimeRun:
    1. Set the duration to 10 minutes

The Java method code is listed below which just calculates the duration since last time the workflow ran till now in minutes

package sfsynchwithretrypattern;

import java.time.Duration;

import java.time.LocalDateTime;

import java.time.ZonedDateTime;

public class StaticHelpers {

    public static long getDuration(ZonedDateTime lastTime) {

        LocalDateTime now = LocalDateTime.now();

     Duration duration = Duration.between(now, lastTime.toLocalDateTime());

     return Math.abs(duration.toMinutes());

    }

}

StoreRetryAccounts Workflow

Figure 13: StoreRetryAccounts SubWorkflow

  1. Check if there are stored RetryIDs
    1. RetryIDS stored: Append the new IDs to the existing IDS
    2. Does not Exist: set the store load to the new IDs
  2. Store the updated value

ProcessRecords SubWorkflow

Figure 14: ProcessRecords SubWorkflow

  1. Retrieve accounts with IDs
  2. For each retrieve account IF
    1. Check if the Account info exists in the DB
      1. Exists: update the account information
      2. Does not Exist: Insert a new record

    Note here I am taking an new records and saving them in the retry ID to simulate rejections. This should be moved to where you receive results and the errors

RetryProcessing Workflow

The retryprocessing workflow is triggered by a schedular, it starts with:

  1. Check if there are any retry id stored
    1. Exists: retrive the stored IDs and process them
    2. Does not Exist: Log no Stored IDs were found.

Conclusion

This is a good way to handle transient errors that occasionally occur during integrating system, when a simple retry might resolve the issue rather than having to ask the user to re-submit or getting support to chase the error. I hope this helps you in your projects. Feedback is welcome.

Figure 15: MySQL DB Table with Updates

1: Practically Designing and API to be An Asset

Any software you design will be used in ways you did not anticipate, that is especially true when you are design API’s which nowadays refers to Web REST APIs. There are different audiences or users for any API. There are the direct API users you know of that are defined in the specifications or solution design/architecture documents, like Web or Mobile clients for example. Then there are the ones you did not anticipate that would come at later stages. For example the API might be used to synchronize data with another system or to extract data for migration to another system. Nowadays, APIs are being considered as assets that would live longer than the projects or systems they are being built for. Taking that into account, there are many things that needs to be considered when designing an API. Let us assume we are designing and API for Authors/Books microservice as shown in the diagram below.

 

 

In the Book Author example, we want to implement CRUD (Create, read, Update and Delete) API for Author and Book entities. The requirements for this API

  1. Search and listing functionality to:
    1. Get a List Authors with various search terms
    2. Get author books
    3. Search books by Author, Genre
  2. Add, update, delete Author or Book

To implement these requirements and have this API as an asset for later use we take the following steps

1: Define the Data type for the API Data Objects

Based on the requirement we first define the schemas for the Author and Book objects that the API will support.

For each resource the API supports we define a schema for:

  1. Data Manipulation Object
  2. Full object
  3. Full Object with HATEOAS (Links for operations)

In RAML we can define those objects as follows :

#%RAML 1.0

title: GT Books API Types

types:


AuthorMod:


description: This is Author for Data Manipulation


type: object


properties:


Name:


required: true


example: Moustafa Refaat


description: Author Name


type: string


Nationality:


required: true


example: Canadian


description: Author Nationality


type: string


Date-of-Birth:


required: true


example: 2018-12-09


description: Author Date of Birth


type: date-only


Date-of-Death:


required: false


example: 2018-12-09


description: Author Date of Death


type: date-only

 


Author:


description: This is the Full Author


type: AuthorMod


properties:


Id:


required: true


example: 1


description: Author Id


type: integer


Age:


required: false


maximum: 200


minimum: 8


example: 10


description: Author Age


type: integer

 


AuthorHateoas:


description: Author with Hateoas information LINKS


type: Author


properties:


Links:


required: true


description: Property description


type: array


items:


required: true


type: Link

 


BookMod:


description:
Book Info for Data Manipulation


type: object


properties:


AuthorId:


required: true


example: 1


description: Author Id


type: integer


Name:


required: true


example: Example


description: Book Name


type: string


Genre:


required: true


example: Example


description: Book Genre


type: string


Stars-Rating:


required: false


maximum: 5


minimum: 0


example: 1


description: Book Rating


type: integer


ISBN:


required: true


example: Example


description: Book ISBN


type: string


PublishDate:


required: true


example: 2018-12-09


description: Book Publish Date


type: date-only

 


Book:


description: Book Info


type: BookMod


properties:


Id:


required: true


example: 1


description: Book Id


type: integer


AuthorName:


required: true


example: Moustafa Refaat


description: Author Name


type: string

 


BookHateoas:


description: Book Information with Hateoas links


type: Book


properties:


Links:


required: true


description: Property description


type: array


items:


required: true


type: Link

 


Link:


description: Hateoas LINK


type: object


properties:


href:


required: true


example: /Book/10


description: URL Link


type: string


rel:


required: true


example: GetBook


description: Operation


type: string


method:


required: true


example: GET


description: HTTP Method Get, PUT,..


type: string

 

2: Define URLs Resources for the API

For each Resource define and implement all the HTTP methods (Get, Post, Put, Delete, Patch, Head, Options) even if you are not going to use them now. You can make the implementation return “403 forbidden” message to the client to indicate that this operation is not supported. For our example we will have

  • /Authors
    • Get: Search/List Authors, return body list of authors matching the search/list criteria with headers containing the paging information
    • Post: Create a new Author, return created author
    • Put: Not Supported return “403 Forbidden” error
    • Delete: Not Supported return “403 Forbidden” error
    • Patch: Not Supported return “403 Forbidden” error
    • Head: Return empty body
    • Options: returns the supported methods by this resource “Get, Post, Head, Options”.
  • /Authors/{id}
    • Get: return author with supplied ID
    • Post: Not Supported return “403 Forbidden” error
    • Put: Update the author and return the updated author
    • Delete: Deletes the author
    • Patch: Not Supported return “403 Forbidden” error
    • Head: Not Supported return “403 Forbidden” error
    • Options: returns “Get, Put, Delete, Options”
  • /Authors/{id}/Books
    • Get: Search/List of books for Author, return body list of books matching the search/list criteria with headers containing the paging information
    • Post: Create a new book for author with Id returns created Book
    • Put: Not Supported return “403 Forbidden” error
    • Delete: Not Supported return “403 Forbidden” error
    • Patch: Not Supported return “403 Forbidden” error
    • Head: Returns same as Get with empty body
    • Options: Returns “Get, Post, Head, Options”
  • /Books
    • Get: Search/List of books, return body list of books matching the search/list criteria with headers containing the paging information
    • Post: Create a new book for author with Id returns created Book
    • Put: Not Supported return “403 Forbidden” error
    • Delete: Not Supported return “403 Forbidden” error
    • Patch: Not Supported return “403 Forbidden” error
    • Head: returns same as Get with empty body
    • Options: returns “Get, Post, Head, Options”
  • /Books/{id}
    • Get: Returns the book with ID
    • Post: Not Supported return “403 Forbidden” error
    • Put: update the book
    • Delete: Deletes the book
    • Patch: Not Supported return “403 Forbidden” error
    • Head: Not Supported return “403 Forbidden” error
    • Options: returns “Get, Put, Delete, Options”

 

To be continued…

MuleSoft: Understanding Exception Handling

I have been approached by several developers taking the Any point Platform Development: Fundamentals (Mule 4) training about the Exception Handling and the different scenarios in Module 10. The way it is described can be confusing. So here is how I understand it. Any MuleSoft flow like the one below

How this would be executed? Any Point studio and MuleSoft Runtime would convert it into a Java byte code. So it would be generated as a method or a function in Java. MuleSoft would put the code for this function within a Try -catch scope. If you have defined exceptions handlers in the error handling module it will emit code to catch and handle those exceptions. If there is not and there is a global error handler, it will emit code for the catch exceptions of the global error handler. Here is the thing that catches developers by surprise. If you have defined local handlers, then those cases are the only cases that would be handled and not the combination of the local cases and global error handler case, only one of them if there is a local error handler defined then that is it if there is not then the global error handler is emitted as catch cases

The 2nd point is On Error Propagate and On Error Continue options. If you chooser on Error Propagate then the coded emitted will throw the caught exception at the end of each catch. If you chose On Error continue then the Exception is not thrown. Think of it as if the code written below If you have been a Java , C#, C++. Or Python developer you should understand this basic programming concepts.


public void MianMethod(){
try {
OnErrorPropagate();
OnErrorContinue();
} catch (Exception E)
{
// default handler or global handler if defined
}
}
public void OnErrorPropagate() throws EOFException
{
try{
throw new EOFException();
}
catch( EOFException e)
{
Logger.getLogger(“ExceptionHandler”).log(Level.SEVERE,“Errot”,e.toString());
throw e;
}
}
public void OnErrorContinue()
{
try{
throw new EOFException();
}
catch( EOFException e)
{
Logger.getLogger(“ExceptionHandler”).log(Level.SEVERE,“Errot”,e.toString());

}
}
Hope this helps

MuleSoft: MCD Level 1 Mule 4 Certification Experience

OK Passed the Exam. How was it. I cannot tell you what the questions was and frankly I do not quite remember them. But here are my thoughts about the exam.

  1. You must go through the training course (which is free online, do all the exercises as there are concepts that are not in the slides or materials. And do the DYI exercises. I personally did them maybe 4 or 5 times. And I took the 3.8 online free course though that might confuse you as there changes between 3.8 and 4.0 like flowVars which is gone completely.
  2. I would recommend going quickly over the mule runtime documentation. And just trying to build a practical example.
  3. An understanding of Java and Spring either MVC or Boot frameworks would help but not necessary as it will help you understand how flows are translated into Spring code then compiled
  4. If you have time on your hands, go to git hub and download the free Sample for MuleSoft from MuleSoft and the open source code. Yes, that is an overkill.
  5. Now how about the questions, They are mostly tricky questions, most of the answers are extremely similar. You have to consider them thoroughly and find the best answer. Many are very simply minor colon, or semi-colon difference. Very low level syntax error so yeah if you have special glasses for the computer use them!.
  6. If you are taking the course from Home make sure you turn off your cell phone, phone etc. and do not speak to yourself. And yes you will not be able to use your big screen TV, you will be limited to the laptop screen.
  7. Hope this helps. I wish I can say it was easy I answered it in almost halftime with reviews, but I was really annoyed by the questions and every question is just trying to trick you.

MuleSoft: Tricky Question in the DataweaveTraining Quiz

I am working on MuleSoft certification and taking the MuleSoft 4.1 Fundamentals course. An interesting question in the module quiz is as bellow

Refer to the exhibit. What is valid DataWeave code to transform the input JSON payload to the output XML payload?

Answers

A.


B.


C.


D.


So here we need to have XML attributes so the “@” is required to define the attributes this disqualifies options B and D. Now A and C look very similar except that C uses a ‘;’ yep a semi-colon that is invalid, so the only correct answer is A.

The interesting thing about this question is that it is a small hidden trick. Maybe that is the kind of questions, we should expect in the certification exam?

MuleSoft: File:List Interesting Observation

Working with MuleSoft file connector, I was expecting that the File->List (https://docs.mulesoft.com/connectors/file/file-list) operation would return a list of fileInfo objects (you know path, size etc) but it actually it returns a list of the contents of the files in the directory. This seemed odd to me as the documentation states


“The List operation returns a List of Messages, where each message represents any file or folder found within the Directory Path (directoryPath). By default, the operation does not read or list files or folders within any sub-folders of directoryPath.
To list files or folders within any sub-folders, you can set the recursive parameter to


https://docs.mulesoft.com/connectors/file/file-list

Here is the sample I was working with

I was intending to put a read file operation in the foreach however that just gave me an error

Here is sample of the logged messages

That was a head scratch-er I thought I had done some mistake in the list parameters, but it seems that is how the file connector list operator works. Below you will see that part of the message for each fine the typeAttributes have the fileInfo information.

What are the Downsides of a Microservice based solution

A Microservice based solution has the following downsides:

  1. Distributing the application adds complexity for developers when they are designing and building the services and in testing and exception handling. It also adds latency to the system.
  2. Without a Microservice-oriented infrastructure, An application that has dozens of Microservices types and needs high scalability means a high degree of deployment complexity for IT operations and management.
  3. Atomic transactions between multiple Microservices usually are not possible. The business requirements must embrace eventual consistency between multiple Microservices.
  4. Increased global resource needs (total memory, drives, and network resources for all the servers or hosts). The higher degree of granularity and distributed services requires more global resources. However, given the low cost of resources in general and the benefit of being able to scale out just certain areas of the application compared to long-term costs when evolving monolithic applications, the increased use of resources is usually a good tradeoff for large, long-term applications.
  5. When the application is large, with dozens of Microservices, there are challenges and limitations if the application requires direct client-to-Microservice communications. When designing and building a complex application based on Microservices, you might consider the use of multiple API Gateways instead of the simpler direct client‑to‑Microservice communication approach.
  6. Deciding how to partition an end-to-end application into multiple Microservices is challenging. As You need to identify areas of the application that are decoupled from the other areas and that have a low number of hard dependencies. Ideally, each service should have only a small set of responsibilities. This is like the single responsibility principle (SRP) applied to classes, which states that a class should only have one reason to change. 

 

 

Implement Rest API in MuleSoft, Azure Logic Apps, Asp.Net core or Spring-Boot? MuleSoft: Step1- Defining an API in RAML

I have been working lately on comparing on comparing different technologies to build web API’s.. One of the main concerns was if we wanted to build a simple API service which technology would be easier, more productive to develop the service with. To provide a reference comparison I will build the same web service (in MuleSoft, Azure Logic App, Asp.Net Core, Spring Boot) and provide my notes as I go. The web service would provide the following functionality

  1. CRUD operations on an Authors entity
  2. CRUD operations on BOOKS entities where books are related to authors

All the Read (queries) should support:

  1. Filtering
  2. Searching
  3. Paging
  4. Supports Levels two and three in Richardson Maturity Model(see my previous post https://moustafarefaat.wordpress.com/2018/12/11/practical-rest-api-design-implementation-and-richardson-maturity-model/) . This means based on the Accept header of the request return the results as either:
    1. Pure JSON
    2. With HATEOUS

I will start with MuleSoft implementation.

Step 1. Define the API in RAML

With MuleSoft you get AnyPoint portal and you get the design center, which helps you designing the API RAML. There is API Designer visual Editor which can help you in the beginning.

 

 

 

Though it has many weakness such as:

  1. Once when you switch to RAML editor you cannot go back.
  2. You cannot define your own Media Types you have to use form the list.

 

To finalize the API definition in RAML I had to manually edit though the editor was helping to get started. Below is a fragment of the API in RAML (The full solution will be published on my GitHub https://github.com/RefaatM )

Notice in the RAML that I have defined two responses for the Get operation of the Authors Resources. Full RAML is at (https://github.com/RefaatM/MuleSoftRestAPIExample/tree/master/src/main/resources/api)

#%RAML 1.0

title: GTBooks

description: |


GTBooks Example

version: ‘1.0’

mediaType:

application/json

application/xml

protocols:

HTTP

baseUri: /api/v1.0

 

types:


CreateAuthor:


description: This is a new DataType


type: object


properties:


Name:


required: true


example: Moustafa Refaat


description: Author Name


type: string


Nationality:


required: true


example: Canadian


description: ‘Author Nationality ‘


type: string


Date-of-Birth:


required: true


example: ‘2018-12-09’


description: Author Date of Birth


type: date-only


Date-of-Death:


required: false


example: ‘2018-12-09’


description: Author Date of Beath


type: date-only

 


Author:


description: This is a new DataType


type: CreateAuthor


properties:


Id:


required: true


example: 1


description: Author Id


type: integer


Age:


required: true


maximum: 200


minimum: 8


example: 10


description: Author Age


type: integer

 


AuthorHateoas:


description: Author with Hateoas information LINKS


type: Author


properties:


Links:


required: true


description: Property description


type: array


items:


required: true


type: Link

 

 


Link:


description: Hateoas LINK


type: object


properties:


href:


required: true


example: /Book/10


description: URL Link


type: string


rel:


required: true


example: GetBook


description: Operation


type: string


method:


required: true


example: GET


description: ‘HTTP Method Get, PUT,..’


type: string

/author:


get:


responses:


‘200’:


body:


application/json:


type: array


items:


type: Author


application/hateaos+json:


type: array


items:


type: AuthorHateoas


‘304’: {}


‘400’: {}


‘500’: {}


headers:


Accept:


example: ‘application/json ‘


description: application/json or application/hateaos+json


type: string


queryParameters:


sort-by:


required: false


example: Example


description: sort by


type: string


filteryby:


required: false


example: Example


description: Property description


type: string

 

(.. to be continued)