JTD-DesignerSeries-1-PlatformSkills

Trailhead Developer Modules [Beginner, Intermediate]

I will use my WebServices experience and will try to provide a learning pattern that may be helpful. I read that there are generally 2 approaches to designing interfaces, and there may be others as well, either Top-Down or Bottom-Up. Depending upon where you stand in the enterprise, Architecture or Delivery, you may want to manage a design a bit differently, but my take would be to go through most of the beginner developer modules if not all.

Platform Skills

Let's start by taking the basic understanding of the tools & technologies supported by the salesforce platform.

I. Lightning Experience
Improves productivity & coherence for sales & service teams, and simultaneously provides mobile friendly platform tools.

1. Lightning Experience is next generation application upgrade for salesforce classic, and team should develop an understanding that transformation analysis is needed for migration from classic to lightning.

[Lightning Experience Basics]

II. Visualforce
UI framework for classic users, and getting supplemented with lightning components in lightning experience.

1. Develop conceptual expertise of visualforce, complete modules with visualforce skills and deep dive into the visualforce section of developer guide.

[Visualforce Basics]

III. Apex
In Salesforce classic ecosystem, Visualforce components builds the UI layer, and Apex language defines the controller layer (MVC Architecture) that binds the UI to the Data Objects (sObjects).

1. A programmer should build on the understanding of Object Oriented Principles, and deep dive into ‘how governor limits supports multitenant architecture’, ‘how to use SOQL & DML into apex to interact with sObjects persistence layer’. Apex Triggers enable developers to create processing constructs, and perform pre-processing / post processing logic on database events.

[Apex Basics & Database, Apex Triggers]

IV. Lightning Design System
Enables standard look and feel, required for enterprise applications, by providing components like Grid System, components like Card, Tile etc. It also suggest structured approach to creating different page layouts for salesforce apps.

1. Lightning Design System supplemented with Remote Objects, Javascript remoting & Rest APIs to access Salesforce Data, helps builds components that can be composed to create apps on lightning platform.

[Lightning Design System]

V. Lightning Components
Simply said, lightning components is powering the lightning experience, rendered on client side just like other Javascript frameworks like Angular / React.

1. Developers usually create the building blocks by creating component bundles [component, controller, helper...] by applying the design principles like loose coupling, composability. Coarse Grained components can communicate with each other by using platform services like lightning events, attributes, aura enabled server side controller methods.
2. Lightning Components can then be configured or added to different containers like lightning pages, lightning app builder, salesforce mobile app to provide enriching lightning experiences.

[Lightning Components Basics, Lightning Component Core Concepts, Lightning Components Skills & Tools]

V. Lightning Data Service
LDS simplifies the data management tasks enabling related components to minimize server trips, cacheing data, handling consistency & notifications across multiple components.

1. LDS can enable CRUD operations by building components that uses force:recordData. force:recordData uses attributes [recordId, targetFields] along with component attribute to retrieve the record of the sObjects.  

[Lightning Data Service Basics]

VI. Lightning Apps
Lightning Apps is a container service with standardization of lightning experience, which can be configured to provide custom branding & navigation. Lightning Apps can be composed from building blocks like Object tabs, lightning pages, standard & custom lightning components to provide rich functionality to users.

[Lightning Apps]

VII. Lightning Flow
Lightning Flow provides guided experiences, process automation & approval functions with tools like Process Builder & Cloud Flow Designer.

1. Event based record changes, sending emails or chatter integration can be handled by creating simple processes using Process Builder.
2. Cloud Flow Designer can enable complex tasks like guiding users through different visuals, passing collections as variables. Flows can be distributed through flow components & monitored through flow interviews.

[Lightning Flow]

Designer Aside
a) In classic upgrades, start reusing the lightning tools gradually for the new functionality and perform analysis & testing on existing functions to document feasibility analysis.

Links & References
a) https://trailhead.salesforce.com/modules/lex_migration_introduction
b) https://trailhead.salesforce.com/modules/visualforce_fundamentals
c) https://trailhead.salesforce.com/modules/apex_database
d) https://trailhead.salesforce.com/modules/lightning_design_system
e) https://trailhead.salesforce.com/modules/lex_dev_lc_basics
f) https://trailhead.salesforce.com/modules/lightning_data_service
g) https://trailhead.salesforce.com/modules/lightning_apps
h) https://trailhead.salesforce.com/modules/business_process_automation

Build with Mule - 101

Context

In Design with Mule - 101, we understood that mule runtime addressed integration

challenges by creating components, filters and flow as a medium passing payload from Station A to Station B. Application Developers, primarily adept at Spring frameworks, used mule ESB & even extended to create custom enterprise service bus implementations. I, being an Integration Developer & not core Java Developer had relied on Java EE 6 implementations & SOA enablement tools from Oracle Weblogic ecosystem, and there are others like me from IBM Webspehere ecosystem.

It is quite important to differentiate Application Integration from System Integration, but either ways, it would be really beneficial to learn underlying principles of Spring framework like Dependency Injection, cross cutting concerns and how packaging of spring modules are defining next generation Microservices architectures.

Mulesoft Anypoint Platform offering has approached on-premise & cloud deployments by revamping the runtime from 3.7 onwards, CloudHub as an Integration Platform that supports hybrid deployments along with providing developers & architects the Anypoint Studio IDE & ever growing cloud connectors.



Runtimes

Mule runtimes are broadly classified as 3.x & 4.x, and with salesforce acquisition of mulesoft, we, as integration consultants, should start treating flows as lego building blocks of SAAS ecosystem, along with components of heterogeneous microservices enabling digital transformation implementations.

At a basic level, I think Mule 4.x has simplified the message model, along with Dataweave as a scripting & transformation engine to standardize the mappings & enable tasks like validation, enrichment as message transition through different stages from source to destination.

Some complex patterns have also been introduced like streaming, improved error handling & reconnection strategies to support the cloud deployments and SAAS ecosystem.



Anypoint Platform Tools

Anypoint Exchange can be deployed as a central enterprise repository to discover, share and incorporate assets.

Design Center helps teams to discuss various aspects of an API by creating a RAML specification through a Web UI and simulating the user stories with data without concrete underlying implementations.

Anypoint Studio provides a development environment for creating concrete implementation of Integration specs using inbuilt capabilities of components, filters, transformers, connectors of mule runtime.

Anypoint Monitoring takes the agent installation to next level by providing capabilities beyond collecting data and allows Ops teams to monitor logs, create alerts and dashboards.

API Functional Monitoring allows white box testing, black box testing and runtime monitoring capabilities by importing the BAT testing framework defined using DWL language.

Anypoint Secret Manager uses Object Stores to provide an offering to manage keys, certificates in the cloud and enable robust security implementations like SSL, VPC for CloudHub APIs.

Anypoint Visualizer is a graphical tool that helps you define the APIs, Mule flows and other data generating systems as nodes in the Application Network and provide troubleshooting capabilities along the paths in story execution.

API Manager is a runtime that manages an API and governs the API lifecycle across different versions, provide capabilities like managing SLA tiers, OAuth Authorization scheme by applying various policies.

Runtime Manager is used to manage deployments of mule app from a single UI to both cloudhub and on-premise installations.

Anypoint Runtime Fabric streamlines the deployment of mule runtimes and other artifacts to IAAS cloud providers by leveraging the container technologies like Docker & Kubernetes.

Anypoint Access Management enables multi-tenet approach to authentication & authorization by using Orgs, Users, Roles & Environments similar to SAAS applications.

Anypoint MQ is a multi-tenet cloud messaging service that allows designers to leverage integrated persistence layer in anypoint ecosystem when implementing asynchronous patterns.

Design with Mule - 101

How Integrations have Progressed

1990 - 2000s (ERPs, Java , Dot Net, RPCs)
Couple of decades ago, when data has to flow from one system to another, we will do three things, we will take source system as origin point, destination system as another point and develop the data mapping. We call these kinds of integrations as point to point. Symbolically, you as data is going from Station A to Station B by a train medium.

Mulesoft realized that there is lot of donkey work, and it can be handled by pre-built configuration and incubated an open source ESB project on spring framework, MULE ESB.

2000 - 2010 (SOAP, WSDL, XML, SOA)
Sometimes, in first half of 2000, SOAP protocol provided standardized approach to Interface through WSDL definition, and architects applied patterns like SOA, ESB, PUB-SUB to create layered services and data started flowing from multiple sources to multiple destinations. Symbolically you as data is going from Station A to Station B through a junction by train as a medium.

Mule Architects understood that webservices will primarily address real-time scenarios and we need a different approach for large data volumes, and created extensions to ESB framework, chunking large dataset into sizable batches, and enabled reporting capabilities of Success, Failures, Error Handling and Reprocessing which was quite manual & custom developed before 2000s.

2010 & Onwards (REST, Cloud, SAAS, Mobile, APIs)
Sideways, there was an interesting development started in the second half of 2000, with cloud computing and really from the integration perspective, source and target systems getting established into the cloud along with 3 decades of on-premise implementations. ESBs & other Integration frameworks started implementing REST architectures to connect to Web APIs, SAAS applications (Salesforce, Workday, NetSuite) through enterprise APIs.

Leadership at Mulesoft, opened up several initiative and asked integration consultants to take an API Led Connectivity approach & use standards like RAML to cloud based implementations, which I think is an extension to SOA Architecture approaches, and provided CloudHub and Anypoint Platform as a deployment engine in the cloud.

Last I know is that Salesforce has acquired Mulesoft to enhance their Integration Cloud offering, and I am quite eager to participate in Microservices implementations to enable next generation trends like IOT, Containers, Blockchain etc.

Understanding API Led Connectivity

Experience generally starts from an interaction by a user, customer, system, device etc, and data travel multiple layers or boundaries to create an impact or impression.

In bottom up approach, we start with a System Layer, where contracts either don't exist or not really consistent. Usually intricacies involved are different authentication, formats, protocols & deployments. So we create a layer of System APIs standardizing these differences.

We then connect multiple systems by using a layer of core system assets without worrying about the connectivity & network issues, to define a layer of Process APIs to define processes that uses capabilities across multiple systems. These process APIs can then create value for Line of Businesses (LOBs).

Experience APIs are your answer to the digital economy ecosystem that orchestrates Enterprise Process APIs to really create revenue generating businesses like AWS, Google Maps etc.

Muleys, at a system layer create flows by using connectors dataweave transformation engine to generate System APIs, and API Designer uses RAML standards to help designers iterate through an API lifecycle.
Methodology [Iterate with Design, Dev / Test, Deploy, Operate]



API Lifecycle

Application Networks, as I heard it is based on the semantics of web architecture and a lot of it goes beyond my understanding. But simply it has to do with engage module which may mean extending reusable assets of an enterprise.

As an offering of Anypoint Platform, designers can use Design Center, API Designer, API Console & Notebook, ApExchange to create simulated specifications with the help of mocking service.

Developers can then identify connectors and scaffold mule flows from the specification artifacts which can be extended in Anypoint Studio with components, filters and simultaneously support cross cutting concerns related to performance, reliability, security, infrastructure. MUnit can be leveraged for testing flows and mocks really facilitate faster integration testing.

APIs can then be deployed using Runtime Manager on the cloudhub / or other infrastructure cloud providers, policies can be enabled using API Manager and command line CLI can be used to establish DevOps capabilities.



Two Cents

Let's say as a consultant, you would have to understand the requirements, systems, processes, people and then use Mulesoft Anypoint Platform expertise to deliver value on mule projects along with honing your skills, as the Integration Ecosystem is changing quite a bit.

Figure Out with Trailhead

Confusion

Earlier, I was really confused with the plethora of technologies, bombardment of frameworks [steep learning curve from XML to JSON: acute angle with 30 degree going toward 45], figuring out what is the way forward for an Integration professional and for many others like me.
Everyone, if not all, are discussing about cloud technologies, mobile & social and enterprise architecture has really gone into the Web.

What are you

Many of us asking what are we doing today and how we are going to relate to these trends. Few have figured it out and are leading communities & practices, and when you listen to them learning curve looks less steep and oh ya, we can stay at 30 degrees and you start to look for opportunities in midst of problems. Anyways, for us in the CTA journey, we have narrow it to SAAS / PAAS layer in salesforce ecosystem and enjoy the support from community, trailheads, certifications & events.

Situations

Each of us has some experience, and has attained knowledge about the ecosystem either through projects, trails and a large number of us are hitting certifications. As I am developing my learning patterns, I am understanding that salesforce ecosystem is expanding with every release, and each one of us is tackling their situation differently based on their experiences and other factors.

Tackling

How we have to tackle a situation can be an iterative process, which is like applying agile approach to the learning.

1.GOAL

Develop an understanding of salesforce ecosystem by achieving a Expeditioner rank and [because I have development background], I would like to target the Platform Developer 1 certification.

1.APPROACH

I assumed that with 1.Goal, you are at the centre [Trailheads] of the a ecosystem, and community, certifications, events & projects are connecting dots that surrounds it.

Like a web application, I will recommend trails as an entry point, which will push you to one of the connecting dots of the ecosystem as you do them, and at times you will have to pull yourself back at the center again.

1.COMPLETION

It took me couple of months to acquire the mountaineer rank, and with support from trails, community and salesforce events like lightning tour, I completed the Dev 1 certification in August.

1.REFERENCES

a. https://trailhead.salesforce.com/users/00550000006yDdKAAU/trailmixes/prepare-for-your-salesforce-platform-developer-i-credential

b. http://www.vandeveldejan.com/tips/for-developers/21-resources-to-study-for-passing-salesforce-platform-developer-i-certification-exam

c. Focus on Force

1.CELEBRATE

I am not working on a billable project, so each day is a bit of enjoyment, but as I passed the certification, I celebrated by not thinking about trails for a whole one week. 😅I did updated by resume and Linkedin with the Credential ID in the celebration week.


Confusion [Achieved the Dev I Certification]

From the center, I added a measurable point towards an edge dot [certifications] and pulled myself back to the center. I know that I have to push myself towards edge dot [projects] a bit more aggressively and simultaneously start working on a next connecting dot towards another edge dot as well [certification].

What should I do next ?

I talked to some of the mentors and realized that Dev I lays the foundation for an advance developer & designer. Though I realized that it is not enough for executing a successful project in a Salesforce Ecosystem and should be supplemented with team expertise & architectural direction.

I explored the requirements for designer & developer II, and administration study guide for few days. I understand that I have to stay at the center of trailheads for the time being.

Along with this, I have to get involved in the community & update the skills in my profile.

How should I proceed ?

Let’s stay optimistic first. Usually when I am reading a book, I may have to go back few pages from the bookmark to comprehend the storyline. So, I look back at my career progression and realized their is an state of being a designer, which is also specified in Salesforce Certification Pyramid [JourneyToCTA].

Let's just say that JourneyToCTA is quite far fetched goal, but I will focus on JourneyToDesigner.




2.GOAL

I am a ranger now, DEV I certified developer and understood that 2nd Goal by running the [Confusion::Situation::Tackling] methodology is towards Designer & Advanced Developer Certifications.

2.APPROACH
With 1.COMPLETION, I am feeling a bit of a trailblazer, and created a small circle around the center by progressing towards edge dots. I will continue to blaze trails, keep up my momentum with blogs & webinars, and start a JourneyToDesigner Series.

I am not going to worry about the Completion for the time being, and celebrate the successes of the community members and take motivation from them to make progress towards my takes.

1.COMPLETION
I am okay, just need to keep focusing.....[blah, blah, blah]🙊😼

1.REFERENCES

a) Start going through trail modules for Developer [Intermediate & Advanced Skill]
b) Join the Salesforce Architecture Community.

1.CELEBRATE

a) I had a soda & slice at Mulesoft Meetup in Atlanta Buckhead on 27-Aug-2018.