Second-Generation Managed Packages

 what are packages ?

1.Package is a container of meta data.

2.It contains a set of related features,customizations and schema.

3.Use packages to move metadata from one Salesforce org to another.

4.As you add, remove or change the packaged metadata,you create many package versions.

5.Each package version has a version number, and subscribers can install a new package version into their org through a package upgrade.

6.you can distribute the package to your customers via AppExchange also.

Pre-requisites for 2GP Package :

1.Enable Dev Hub in your Org.

2.Enable Second-Generation Managed Packaging.

3.Install Salesforce CLI.

4.Create and Register your Namespace.

5.Assign the required permissions to the Developers-

Developers need either the System Administrator profile or 

the Create and Update Second-Generation Packages permission in Dev Hub Org.

Dev Hub Org :

-> As owner of all Second-generation managed packages.

-> To link your namespaces.

-> To authorize and run your force:package commands.

Namespace Org :

-> The primary purpose of the namespace org is to acquire a package namespace.

-> After you create a namespace org and specify the namespace in it, link the namespace org to the Dev Hub Org.

Other Orgs :

-> you can create scratch orgs on the fly to use while testing your packages.

-> The target or installation org is where you install the package.

Create a package :

=================

Create Package :

sfdx force:package:create --name DreamDemo --path source-folder --packagetype Managed

Package Version Creation :

sfdx force:package:version:create --package "DreamDemo" -- installationkey test1234 --wait 10 --codecoverage

Promot the Package :

sfdx force:package:version:promote -package "DreamDemo@0.1.0-1"

Package Ancestors :

==================

-> Only package versions that have been promoted to managed released state can be listed as an ancestor.

-> When we define an ancestor for the packages they inherits the manageability rules of the specified ancestor package.

Note :

Specify the package ancestor in the sfdx-project.json file using either the ancestorVersion or ancestorId attribute. Use the ancestor that’s the immediate parent of the version you’re creating.

"packageDirectories": [

        {

            "path": "util",            

            "package": "Expense Manager - Util",

            "versionNumber": "4.7.0.NEXT",

            "ancestorVersion": "4.6.0.1"

        }

    ]

"packageDirectories": [

        {

            "path": "util",            

            "package": "Expense Manager - Util",

            "versionNumber": "4.7.0.NEXT",

            "ancestorId": "04tB0000000cWwIAE"

        }

    ]

    

"packageDirectories": [

        {

            "path": "util",            

            "package": "Expense Manager - Util",

            "versionNumber": "4.7.0.NEXT",

            "ancestorId": "expense-manager@4.6.0.1"

        }

    ]

    

Best Practices :

1.Work with only one Dev Hub, and enable Dev Hub in your patner business org.

2.Include the --tag option when you use the package:version:create and package:version:update commands.

This option helps you keep your version control system tags in sync with specific package versions.

3.Create user-friendly aliases for packaging IDs and include those aliases in your Salesforce DX project file and 

when running CLI packaging commands.

4.Make use of Scratch Orgs and other source control systems for development instead using the Namespace Org.

5.Always test using Beta package before you actually upgrade package.

Advantages and Gaps of 2GP :

============================

1.Define one Namespace for your company and use it for every package you develop.

2.With 2GP, you can build your application as separate modules.

Smaller functional modules are always easy to develop, test and maintain.

3.Can make use of the flexibility development with the help of source control systems that you use.

Gaps :

1.Component's can't be deleted from packages.

2.Package versions can't be deprecated.

3.Apex VersionProvider isn't supported.

4.A default language for labels in packages can't be specified.

Comparison of 2GP and 1GP Managed Packages

Salesforce Async SOQL

 What is Async SOQL and when to use it?

What is Async SOQL?

Async SOQL is a method to run SOQL queries.

When to use Async SOQL?

When you have to query from a large amount of data( Big Objects containing more than 1 million records) and then copy that data to another custom or standard object to examine the data set easily.

How to use Async SOQL?

You need to create a POST request with the query as the body.

Example of the POST request:

URI: yourSalesforceInstance/services/data/v38.0/async-queries/

Body:

{

   "query": "SELECT field1__c, field2__c FROM CustomObject1__c WHERE probability >90",

                       

   "targetObject": "CustomObject2__c",    

        

   "targetFieldMap": {"field1__c":"field1__c", 

                      "field2__c":"field2__c"

                     }                         

}

Explanation:

- The above POST request will be sent to the org. 

- The SOQL query will retrieve the records and then create a copy of the records in the target object according to the field mappings mentioned in the body.

MuleSoft 4 Fundamentals

 We need software that integrates multiple systems seamlessly.

API-led Connectivity :

API-led connectivity is a methodical way to connect data to applications through reusable and purposeful APIs. 

These APIs are developed to play a specific role, unlocking data from systems, composing data into processes, or delivering an experience.

Three Types of API's :

1.System APIs

2.Process APIs

3.Experience APIs

System APIs :

System APIs, these usually access the core systems of records and provide a means of isolating the user from the complexity of any changes to the underlying systems. 

Once built, many users can access data without any need to learn the underlying systems and can reuse these APIs in multiple projects. 

Think of APIs to access a database, at least the common operations or APIs to ease the access of certain errorless resources.

Note : Encapsulate data systems into an API.

Process APIs :

These APIs interact with and shape the data within a single system or across systems, breaking down the data silos, 

and are created here without dependence on the source systems from which the data originates. 

They only call the system APIs, and, as well as they don't depend on the target channels for which the data is delivered. 

A given process API, you have to think of a transformation, the data coming, for example, from the database to a certain schema delivered by a 

certain web page. Regardless of the web page API and the database API, in the middle, the logic is the same.

Note : Aggregate and process the result of System APIs.

Experience APIs :

Experience APIs are how data can be reconfigured so that it is most easily consumed by its intended audience, all from a common data source rather than setting up separate point-to-point integrations from each channel. 

An experience API is usually created with API-first design principles where the API is designed for this specific user experience in mind.

Note : Expose the data for frontend

API Language :

There are many, but the main ones are Swagger, or you may hear Open API 3.0, and RAML v1. 

RAML is native to MuleSoft.

RAML is a YAML-style language to define an API. 

Main Changes from Mule 3 :

1.Migrating MEL to Dataweave 2.0

2.Added Design Center

3.Flow Designer

4.Exchange

Salesforce Platform Events

 1.Platform events are a special type of object (__e).

2.Platform events only support create/read permission.

3.No SOQL support,you must replay events to retrieve.

4.Fields limited to base data types only (i.e text,date,number,Boolean).

5.you can subscribe to events via Apex,Process Builder and CometD utility (Java or javascript).

Note :

The what happens with the platform event in an event bus is that you have decoupled your information publishers and your information subscribers.

The publisher of information doesn't have to know anything about anybody that's listening. And the subscriber, 

if it happens to fail or have an exception or something like that doesn't walk anybody else from performing actions. 

That's one of the real powers of this platform event model.

The only way to get events is to subscribe to them and potentially to republish them, 

which has to go through the entire stream events from that point onward.

Platform events cannot be edited their immutable.

Platform events have two publication types :

1.Publish Immediately disregards any form of rollback.

2.Publish On Commit honors transaction controls.

Note :

1.You can publish a platform event immediately, which means it hits that bus and it goes. No matter what else is happening in the system.

2.The second option is to wait until after the committee of the current transaction to publish them. 

If you're trying to do something because if you're trying to throw a platform event because a record change successfully, 

you'd want to wait till after commit But if I have an heir, I wanna publish that thing right away.

Note :

1.'Processes' utilize the SAME user that fired the event.

2.'Triggers' utilize the AUTOMATED PROCESS user.

Asynchronous processing :

=========================

It's now known has changed data capture what happens with change. 

Data capture is any record event that happens on that particular object has a platform event published, 

and the body of that event is the fields that are changed.

Events are processed in batches that can scale up quickly.

-> Monitor limits in the transaction and pick up where you left off 

with TriggerContext.setResumeCheckpoint(replayId).

-> Abort and retry a batch from the beginning by throwing an EventBus.RetryableException.

Salesforce Omni-channel

 Omni-channel Channel Types :

Omni-channel is capable of working with two types of channels :

1.Real-time Channels 

2.Asynchronous Channels 

1.Real-Time Channels :

Real-Time Channels are Channels where the person asking support is expecting a real-time answer to their request.

For example, Phone calls or live chat.

2.Asynchronous Channels

Asynchronous Channels are Channels where the person asking support is expecting a reply to their request at a later time.

For example emails or contact forms.

Omni-channel Routing Destinations :

Omni-channel can route Work Items to 3 different destinations.

1.Route to Queue

2.Route to Skill

3.Route to Agent 

1.Route to Queue :

Work items fall in a Queue of Users where Users are then picking up work first-in first-out.

2.Route to Skill :

Work Items are Assigned to the Agents that have the proper skills to work on the request.

3.Route to Agent :

Work Items are assigned to a specific Agent directly.

Omni-Channel Agent Properties :

Agents have properties that Omni-Channel uses in order to select which agent is 

better suited to receive a work Item based on its Routing Destination.

1.Status & Capacity

2.Skills

3.Queue Membership

1.Status & Capacity :

Agents all have a Status,which models their availability, and a Capacity,which models the maximum amount of work they can take.

Examples of Statuses are : Away,Available,On Break

2.Skills :

Agents have a set of Skills that they can leverage to take certain work items.

Work Items can require one or multiple skills to be assigned.

Example of Skills are : English, 2nd Tier,Robot Butler Maintenance

3.Queue Membership:

Agents can be assigned to specific queues,and thus work on Work Items that fall in those Queues.

Examples of Queues are : Billing,Complaint

Omni Supervisor Features :

Supervisors get access to the Omni Supervisor function in Omni-Channel in order to monitor their team easily.

1.Monitor Agents 

2.Monitor Work Backlogs

3.Monitor Assigned Work

Monitor Agents :

Supervisors can monitor the Agents they have access to through the Supervisor Configuration assigned to them.

This includes,the Agent status and status timeline,the Agent's current work and open capacity,how long they've been logged in.

Monitor Work Backlogs :

Supervisors can monitor specific Skill & Queue backlogs to gauge how much work is left to be assigned to agents.

This allows them to have simple visibility on where to focus their efforts.

Monitor Assigned Work :

Supervisors can monitor work that's being worked on.

Using specific channel functionalities,they can even listen in on phone calls,

or see what agents are typing in the chat even before they've sent it.

TelePhony in Salesforce Service Cloud :

1.Open CTI

Open CTI is a telephony javascript API allowing vendors of telephony systems to develop integrations to interact with a 

Salesforce Softphone directly on the end-user's browser.

2.Vendor-Specific Implementation

Vendors also have the possibility to integrate deeper into Salesforce by integrating

with specific Service Cloud functionalities like Omni-Channel or Service Cloud Voice.

Vendor TelePhony Integration Levels :

1.Simple Integration-pure Open CTI integration

A vendor that integrates with Open CTI will only provide a Web-based softphone client for end-users to 

interact with. This means the integration is limited and doesn't integrate with Omni-Channel.

2.Partial Integration -Open CTI with additional functionalities 

A vendor can also add additional functionalities to their integration.

In that case, you have to look at your vendor's documentaion to ensure 

Omni-Channel is included as part of their additional functionalities.

3.Complete Integration - Service Cloud Voice 

A vendor that maintains a Serice Cloud Voice implementation is the most complete 

telephony integration you can find as this leverages Salesforce as the central place

for all telephony actions to happen.

TelePhony & Omni-Channel Integration Benefits :

1.Bi-Directional Agent Status Syncing

One of the key benefits of integrating your telephony in Omni-Channel is that the agent's status 

synchronizes on both systems,allowing your agents to do it in one place only.

2.Handle Phone Calls right from Omni-Channel

 Once integrated,phone calls can be managed inside of Omni-Channel instead of your agents having to manage 

 two different windows,one for the softphone , and the other for Omni-Channel.

3.Record & Transcribe Phone Calls, and much more

 If your vendor implements those functionalities,you can even record and transcribe phone calls right from Salesforce.

 Other functionalities like 'Supervisor Listen In,'Queued Callbacks' or 'Mean Opinion Score'

 are functionalities your vendor cloud provide to you too.

 

Salesforce Chat :

To set up Chat in Service Cloud and route it to Omni-Channel.

 

1.Omni-Channel

Used to route the chat conversations based on your Omni-Channel routing.

2.Emabedded Service 

Used to embed your Salesforce Chat wherever you want (ex: website,app).

3.Einstein Bots

Used to filter your chats and gather pre-information before they arrive to your agents.

4.Agent Chat Console

Used by your agents in order to interact with the chats they have open with customers.