Just Another Dang Blog

Not everything is happy daisies. I’ve been in a roll so far nailing my Salesforce certification but not that lucky with middlewares(had to the retake the boomi certification) and it looks like the same for Mulesoft, after just about a month of working on the platform I decided to seat down the exam while I am still actively involved with an implementation. I might not get the chance for awhile.

I could have spent probably two days more studying.

Things to focus on- would be the
– dataweave syntax
– error handling (questions makes you doubt your answers)
– debugging and what to expect on the output
– data transformation
– accessing and modifying events.

Anyway I re-booked the exam and will be taking it next week. I just don’t feel comfortable that I feel I was close to passing.

Just ran into this when I was creating a new Custom Setting for a new org. The List Settings Type was greyed out.

Found out this is something new for Spring 18. It is now an application level settings that needs to be enabled even for System Administrators.

Starting with the Spring ’18 release, Admins have the ability to control the List type Custom Setting creation. By default, the “Manage List Custom Settings Type” is disabled, which is why Custom Setting type List is greyed out. To allow the creation of custom settings when using application-level data definitions you’ll need to enable Manage List Custom Settings Type.

To enable do the following:
Go to Setup > Data > Schema Settings and toggle button to enable “Manage List Custom Settings Type”

Then go back to Custom Settings.

Quick little tip. On my Ant deployment script for Salesforce I run into an issue where my password which was assigned to a variable contained double dollar sign characters. Ant would by default strip out any string with ‘$$’ sign into ‘$’ because it was expecting a value.

This caused my password to stop working.

I ended up breaking my password into two variables.

from

sf.password = time$$machine

to

sf.password = time$

sf.password2 = machine

Then on my build.xml file, I created a new property to store the dollar value and updated the passwordToken property.

<property name="dollar" value="$" />
<property name="passwordToken" value="${sf.password}${dollar}{sf.password2}${sf.token}"/>

That is the post for the day.

In this post I’m sharing my notes for spec driven development and cover the basics on creating an API specification. Spec driven development is a development process where your application is built in two distinct phases.

• creation of the specification (design)
• development of code to match the spec(development)

What are the phases for spec driven development in the Mulesoft world?

• Design
• Simulate
• Feedback
• Validate

So what is an API Specification and how to create one?

– API specification and definition are interchangeble. API Specification is much more concerned with the overall behavior of the API, and how it links to other APIs.

– To create API Specification we use a language called RAML.

• RAML is a language for the definition of HTTP-based APIs that embody most or all of the principles of Representational State Transfer (REST).
• It is a non-proprietary language to build API specifications
• Data structure is hierarchical and by indentation not markup

Source: https://github.com/raml-org/raml-spec

Where can you start creating RAML?

• Design Center on the Anypoint Platform
• You can use Anypoint Studio
• API Workbench – installed as an Atom package – http://apiworkbench.com/

Some key design features of creating an API Spec on the Anypoint Platform

• Documentation is created from the RAML and shown in the API console
• A mocking service can be used in the API console to test the API
• Make an API discoverable by publishing it to the Private Exchange
• You can publish to the public(needs Mulesoft review)
• API portals are auto generated
• Automatically generated api endpoint is created that uses mocking service
• API portals can be shared to internal or external users
• Share the API to external developers by making portal public
• You can customize the public portal
  • logo
  • favicon
  • welcome text
  • fonts
  • image

What is a mocking service?

• it is an auto generated api endpoint to use for testing

Those are just the basics and will cover more on upcoming posts.

Been working on Boomi platform for couple months now and here to share a quick tip that I learned earlier. Since Boomi now support Custom SOQL for an operation it however looses the XML profile when you import an object.

The profile can easily be fixed by doing the following.

1. Add a Message shape and add your SOQL
   
2. Add Salesforce Connector
3. Add an Operation and click on Advanced link and choose Custom SOQL
4. Save and run the process
   
5. Inspect the logs and copy the xml and save it as a file
   
6. Create a new mapping shape
7. On the Left mapping click on Choose
8. On Profile type select XML and choose Create New Profile
   
9. Click on Import Profile
   
10. Select your saved file and you are set.

Here is how my process looks like.

Give it a try!