eBook Transition legacy systems Webhook Screen

A quick and simple Salesforce webhook listener

Quick summary: How to set up your Salesforce org to listen for webhooks

Setting up your Salesforce org to listen for webhooks should be easy. Actually, it is easy, but it seems the steps are buried in different places like Horcruxes. I’m going to assemble them here, and if He-Who-Must-Not-Be-Named shows up, he can proof-read this for me.

So, we start with a simple Apex class. There are a bunch of examples of this. The easiest one for a quick start is in the Salesforce blog post “Quick Tip – Public RESTful Web Services on Force.com Sites.” Remember, it is a quick demo. Your final code should look like something between that and the example from the Salesforce Apex Hours video “Salesforce Integration using Webhooks.” My example is:

@RestResource(urlMapping='/hookin')
global class MyWebHookListner {
    @HttpGet
    global static String doGet() {
        return 'I am hooked';}
}

Now, the tricky part is that the Quick Tip blog has instructions and a screen shot of “just need to add MyService to the Enabled Apex Classes in the Site’s Public Access Settings,” followed by a wonderful example of a sample URL. Because I used Sites and Domains customizations once for a Trailhead exercise six years ago, the connection did not immediately click for me, nor the other steps. I will save you the tedium of reading all that I went through, which included pausing the aforementioned video several times to capture the exact steps and summarize them for you here.

In Setup, search for “site” and select User Interface > Sites and Domains > Sites from the results. Create a site here if you don’t already have one (and if it is in production, make sure it is the URL you want).

Now, the tricky part is that the Quick Tip blog has instructions and a screen shot of “just need to add MyService to the Enabled Apex Classes in the Site’s Public Access Settings,” followed by a wonderful example of a sample URL. Because I used Sites and Domains customizations once for a Trailhead exercise six years ago, the connection did not immediately click for me, nor the other steps. I will save you the tedium of reading all that I went through, which included pausing the aforementioned video several times to capture the exact steps and summarize them for you here.

In Setup, search for “site” and select User Interface > Sites and Domains > Sites from the results. Create a site here if you don’t already have one (and if it is in production, make sure it is the URL you want).

 

If you created the domain just now, scroll down after clicking the Register My Salesforce Site Domain button and click the New button at the bottom. Fill in only the required fields (remember, this post title starts with “Quick and simple,” not “Safe and secure” … though you should do that on your own until I write that version), and Save (there may be a delay before the screen refreshes … be patient, as clicking it again will cause it to try to create another site and give you an error message). If you already had a site, click the site name in the list at the bottom of the page to get to Site Details page, specifically, the Public Access Settings button.

Here we want to find the Enabled Apex Class Access link and click it or the Edit button that pops up on hover:

And finally we get to the screen shown in the Salesforce blog post that lets the magic happen:

 

Add your class, save, and you may need to navigate again to the bottom of the Sites page and click the Activate button to activate the site you have created.

Now, take the site URL and add services/apexrest/[urlmapping] (the value used in you Apex code for urlMapping=) and go there. (The full URL will look something like “https://my-developer-edition.na9.force.com/services/apexrest/myservice,” with the bold text matching your site address and urlMapping, respectively.)

If all went well, you should see what ever nifty response you set as a return string, at which point you can get rid of the return string and do the serious stuff you want to do with your webhook. If not, drop me a line describing exactly what happened and I’ll try to figure out which of us skipped a step.

Also, for that security stuff I had said I wouldn’t cover, I do have to recommend that you:

  • Make sure that you handle all verbs and kill off the ones that aren’t expected.
  • Check the referrer for matching where you accept requests from.
  • Validate the format of the request matches what you expect.

Again, there may be more details in a future post. This one was just to make sure I didn’t have to go on another Horcrux quest.

To summarize all of above cheekiness into a set of steps:

  1. Your webhook class will be a RestResource.
  2. You must have an active Salesforce Site.
  3. You need to enable your RestResource Apex Class under Public Access Settings for Salesforce Sites.
  4. Your listener URL will be your Salesforce Site address/services/apexrest/urlMapping.
  5. You should secure the heck out of the class and processes before letting it access anything beyond a simple response string.

Originally published at Logic20/20 Insight

If you found this interesting, please share.

© Scott S. Nelson

Is IT a cost center or profit center?

Quick summary: Transforming IT from a cost center to a profit center starts with more strategic business decisions concerning technology.

There are parts of IT that are costs, such as vendor-provided platforms, and this may confuse some into lumping all of IT into the cost center bucket. IT can (and should) be a profit center. Efficient IT can improve profit margins and growth. It is the business practices and decisions to treat IT as a cost center that eventually turn it into one.

Just as applications are useless without users, Enterprise IT that doesn’t provide value eventually won’t have an Enterprise to provide value for. What is often forgotten is that business capabilities are only as reliable as the processes that support them, including Enterprise IT processes. Many may believe that technology companies are the fastest and strongest in the market because they are more valuable, and I believe they are more valuable because they understand the value of technology and treat it as an investment rather than a cost of doing business.

Comparing Apple™ to apples

The difference in the nature of products fosters the confusion. A widget (or apple, to clarify the subheading) company that has a failure in the manufacturing process can go bankrupt, whereas a software company that has a defect can just issue a patch, ergo, issues with software are less important than issues with other enterprise activities. The misconception is that the software product is the same as the enterprise software that distributes it or the systems that communicate with customers. If that enterprise software fails for either the software company or the widget company, they are going to have a bad quarter (or worse). Tech companies know this, and it is why so many that run at a loss for a long time are later the biggest players. A deeper look into companies not considered as technology companies will show that the highly successful ones treat their Enterprise IT systems as if they were technology companies.

A clear indication of a company misunderstanding the value of their enterprise systems is the accumulation of technical debt. Technical debt is the result of Enterprise IT taking shortcuts to meet business objectives. For widget companies, or even widget service companies, this seems like a good trade off, because widgets are more important than enterprise systems to a widget-based company. Like any debt, technical debt grows exponentially when the principle is not paid down. True, that is not how math works, but it is how debt works, because the same attitude towards debt that focuses on interest payments and not the principle also tends to acquire more debt in other areas—or attempts to address the debt by restructuring it into new debt that is larger because there is a cost to the restructuring.

Getting interested in debt

The debt is a result of treating shareholders as Enterprise IT stakeholders. The business is the stakeholder, and while the shareholder may be a stakeholder in the business, it is the responsibility of the business to do what is best for shareholders by seeking ways to increase value in a sustainable manner. Enterprises that are spending money on paying loan interest are not giving that money back to the business and the shareholders. Eventually, this will erode share value.

The cost of technical debt is that expanding business capabilities takes longer or costs more or both. Unmanaged technical debt reduces quarterly earning capabilities, sometimes exponentially in relationship to value realized. Eventually, the debt becomes “real” enough that the business takes notice and invests in dealing with it…or an organization with a much lower level of technical debt takes over the company and enjoys the profits of applying their own solid, stable infrastructure to selling widgets in addition to their other successful enterprises.

“Lies, damned lies, and statistics”

Another perspective that leads to technical debt and higher IT costs is quarterly reporting. IT in the profit column puts a focus on ROI and a culture of seeking efficiency in providing new and improved features. If IT is in the cost column, cutting costs sounds good on the quarterly report, but what reduces IT spending in one quarter will increase the cost in a future quarter, both in maintenance and impact to further growth initiatives. Technical debt is less of a metaphor than an understanding of the true monetary value of IT.

Some may take the viewpoint that the need to update IT periodically is an argument for it to be considered a cost center. That need is (generally) driven by two things: the accumulation of technical debt making it cheaper to replace, or an improvement in the technology that makes an update even more profitable. To be fair, this misunderstanding is exacerbated because there are many initiatives that claim to be driven by the latter when the root motivation is the former.

Bottom line

Thinking of shareholders as IT stakeholders is a recipe for fragility. If technology is not improving profitability, then it either needs to be updated or discarded for the right technology. The only way to cut costs in the long term is to invest in reversing technical debt from previous quarters and reap the rewards in next quarters.


Originally published at https://logic2020.com/insight/it-cost-center-or-profit-center/

If you found this interesting, please share.

© Scott S. Nelson

Yet Another Tech Debt Post

Quick summary: Technical debt is the elephant in the room … the same elephant that the blind men were curious about. Understand how perspective contributes to and can resolve tech debt.

Logic20/20 has been involved in many platform migrations and technology refreshes. While there are myriad reasons to make such a major shift, the three key drivers are:

  • Gaining new capabilities
  • Increasing time to market
  • Reducing costs

Most other reasons will fit into one of those three, and usually it is more than just one of the three. All three are valid and valuable reasons to commit what is usually a large amount of resources to achieve. What is seldom acknowledged is that the initial motivation for the expense is to deal with technical debt.

Boom. Yes, that is a big statement. Let me unpack it a bit. Most new capabilities can be added through adapters or integration. Time to market can be severely hampered by technical debt, as can the costs associated with development and maintenance. That isn’t to say that upgrades and technology shifts aren’t necessary, only that the tipping point frequently comes from the accumulation of technical debt.

Once the transition to a new platform (be it an upgrade or vendor change) is complete, what follows depends on whether the influence of technical debt was acknowledged as part of the effort. Organizations that utilize processes, policies, and governance to manage technical debt can find that their ROI from the project will more than justify the expense. Those that do not recognize the contribution of technical debt to the problems with the old way of doing things and believe the issues were only within the platform will find that they will be ready for another migration in as little as one year.

The thing about technical debt is that it is not always recognized because of the different perspectives that result in its accumulation. I think of these as WhatWhy, and How. My experience is that the order of how these perspectives are realized determines the organization’s maturity in relation to managing technical debt. It is when they are recognized in the reverse order that it takes longer to reach a point where the organization is managing technical debt.

How is a technical aspect. It is the use of architecture, design, and implementation solutions that focused on the immediate need over the long-term solutions. At the time the decisions are made that lead to technical debt, the technical team usually knows it is happening and has hopes (if not actual expectations) to address the debt in later releases.

Why is a business problem, and is also more a series of questions than a statement. Was the initial debt incurred by informed decisions? Is the increasing debt the result of planned obsolescence or not knowing the impact? Are they even aware that their drive for business capabilities resulted in technical debt? The diagram at the end of Martin Fowler’s TechnicalDebtQuadrant post is the clearest representation of what leads to technical debt. Frequently the types of conversations necessary to make informed decisions don’t happen because technology and business make assumptions about viewpoints that are generally inaccurate. Communication is always a key factor to enterprise success.

What is a universal, once it is recognized either by the How or the Why: It is architecture and design issues that impede progress through time spent on maintenance and work-arounds. The How cannot change the What unless there is an important Why. In other words, the debt will not be reduced by technical teams unless there is a good reason for the business to pay for it.

The first step is reducing or eliminating the accumulation of technical debt. The second step is to determine how much focu$ will be dedicated to each release to reduce the technical debt. In most cases, this should be a gradual process of adopting new patterns and spending some time in each release refactoring what is related to the release. In some cases, the impact is so pervasive that either an entire release needs to be focused on refactoring or one team needs to be dedicated to it for one or more releases until is manageable again. Whereas most technical debt has a common cause, the path out of technical debt needs to be tailored to the enterprise and the system to be successful.


Originally publihsed at https://www.logic2020.com/insight/tactical/technical-debt-what-why-and-how

If you found this interesting, please share.

© Scott S. Nelson

Random Data post at Logic20/20

Quick summary: Proven successful approaches to generating random test data in JMeter as part of a more complex API testing framework

Random data prevents optimized libraries from caching requests and displaying artificially high performance. It is also useful to test the range of accepted values to ensure that the full range is supported. In addition, random data can help with building negative test cases, which are important both for exercising functionality and for determining whether negative test cases result in performance impacts (which are also a security risk). There are many ways to create random data, and this article provides examples of some approaches I have used with consistently positive results as part of a more complex API testing framework.

Apache functions

There are several functions documented on the Apache site. I find that I need to look beyond the documentation for good examples, and you will need to look beyond this short article for more than one, though this is one I use often: ${__RandomString([length],[characters], [variableName])}:

${__RandomString(${__Random(3,20)},ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz,
              notes.saveSessionNotes.myOrderSessionApi)}

Using JSR223 Samplers

JSR223 Samplers are great for taking advantage of the efficiency of the Groovy language in JMeter. There are two types of random data that are well suited for JSR223 Sampler generation. One is generic data, such as numbers, dates, and alpha-numeric characters with an easily defined pattern. The other is a small sample of specific values that can be used randomly.

The static data stored in the JSR223 Sampler should be as realistic as possible. Extracting the data from a production database copy using a query such as

SELECT DISTINCT [FIELD_NAME] from [SCHEMA.TABLE]

is the best way to get realistic and valid values. In cases where an empty string as input will return null as output, consideration must be given to the impact of skipping the null inputs versus using assertions that need to be very complex in order to handle the nulls dynamically.

Random dates

The example below demonstrates an approach to extract the difference in days between the earliest and latest date, then randomly select a number in that range of days and deduct it from the latest date to create a random test value (in this case for a date of birth):

Date  todayDob  = new Date();
Date  bottomDate = Date.parse('yyyyMMdd', '19010101');
Int   diffDays  = todayDob.minus(bottomDate);
Int   rndDiff   = org.apache.commons.lang3.RandomUtils.nextInt(0, diffDays);
Date  randDob   = todayDob.minus(rndDiff);
vars.put('myApiPersist.dob',randDob.format( 'yyyy-MM-dd' ));

Random strings from list

An object array is easier to read and maintain for simple arrays.

String[] empStatuses  = ['Full time student', 'Unemployed', 'Retired',
                       'Employed','Part time student','Unspecified'];
int      empStatusIdx = org.apache.commons.lang3.RandomUtils.nextInt(0,
                        empStatuses.size());
vars.put(‘myApiPersist.employmentStatus', empStatuses[empStatusIdx]);

In the example above, note that org.apache.commons.lang3.RandomUtils is used instead of the Groovy Random class because of how Random is not actually random and can easily lead to clashes across threads. (There are other functions and approaches as well, and I tend to re-use previous code until a compelling reason to change occurs).

For sets of very small lists, using a random number and the modulus operator is more efficient if the random number is already being generated for another value, as in this example:

String[] patGender = ['M', 'F'];
vars.put(‘myApiPersist.gender', patGender[(int)todayDob.getTime() % 2]);

Two-dimensional arrays

2D arrays are necessary when values must be used in pairs to be valid. For those unfamiliar with working with multi-dimensional arrays, here is an example:

String[][] nearestLocation = [["Don't know","UNK"],["SoCal","42035005"],
                       ["None with 100 miles","OTH"],
                       ["Midwest","20430005"],
                          ["Virtual","ASKU"],
                          ["America South","38628009"]];
int      nearestLocationIdx = org.apache.commons.lang3.RandomUtils.nextInt(0,
                            nearestLocation.size());
vars.put(‘myApiPersist.sexualOrientation', nearestLocation[nearestLocationIdx][0]);
vars.put(‘myApiPersist.sexualOrientationCode', nearestLocation[nearestLocationIdx][1]);

Maps

Maps are an alternative to the 2D array. Here is an example from a file upload API test:

def fileSize = [1,5,10,20];
def extensionAndMimeType = [tif: 'image/tiff', pdf: 'application/pdf', jpg: 'image/jpeg', docx: 'application/vnd.openxmlformats-officedocument.wordprocessingml.document'];
def extensions = extensionAndMimeType.collect{entry -> entry.key};
String filePrefix = fileSize.get(java.util.concurrent.ThreadLocalRandom.current().nextInt(0, fileSize.size()));
String fileExtension = extensions.get(java.util.concurrent.ThreadLocalRandom.current().nextInt(0, extensions.size()));
vars.put('session_file.name', String.format('%sMB_File.%s', filePrefix, fileExtension));
vars.put('mime.type', extensionAndMimeType.get(fileExtension));

Random keys from maps

Sometimes you only need the key from a map at certain points in your test. Rather than maintain two samplers, you can access just the keys.

def fileTypes 		= 	[ 'FileAttachment': 1, 'FileAttachmentOpaqueId': 1, 'ClinicalNote': 3, 'ClinicalNoteTemplate': 4, 'ExternalDocument': 5, 'FaxDocument': 6, 'Multiple': 8, 'CCDABatch': 9 ];
def randomFileTypeKey = (fileTypes.keySet() as List).get(ThreadLocalRandom.current().nextInt(fileTypes.size())).toString();
OR:
def randomFileTypeValue = fileTypes.get((fileTypes.keySet() as List).get(ThreadLocalRandom.current().nextInt(fileTypes.size())).toString());
OR:
def randomFileTypeValue = fileTypes.get(randomFileTypeKey);

Lists

At a certain (arbitrary) level of complexity, a List implementation may be easier to maintain (or it may justify an exception to use a CSV file instead). Here is an example of a List of Lists being used to generate all possible combinations of three sets of health-related parameters:

List<List> testValues = [
  ["FEVER","COUGH","SORE_THROAT"], //v3SymptomsSet
  ["POSITIVE","NEGATIVE","PENDING"], //testResult
  ["YES","NO","INDICATED_BUT_UNAVAILABLE"]];//v2TestedStatus
List<List> patCOVID19ScreeningApiVars = [];//
List temp = [];
void generatePermutations(List<List> lists, List result, int depth, List current) {
    if (depth == lists.size()) {
       result.add(current);
        return;}
    for (int i = 0; i < lists.get(depth).size(); i++) {
        generatePermutations(lists, result, depth + 1, current + lists.get(depth).get(i));}
}
generatePermutations(testValues, patCOVID19ScreeningApiVars, 0, temp);
vars.putObject("patCOVID19ScreeningApiVars",patCOVID19ScreeningApiVars);
vars.put("patCOVID19ScreeningApiVars.Count", (patCOVID19ScreeningApiVars.size - 1).toString())
SampleResult.setIgnore();

Ctrl+C/Ctrl+V

There are some alternate ways to generate random values described in this Stack Overflow thread.

Some key considerations for options to generate a random number:

  1. java.util.Random does not generate true random values. A test in JMeter resulted in the same series of numbers every single run. This can increase the likelihood of clashes between threads.
  2. While org.apache.commons.lang3.RandomUtils is a wrapper around java.util.Random, it is (like most of the Apache Commons collection) a well-designed wrapper that results in values that are more random and tested to result in a different series of values on every test run.
  3. ThreadLocalRandom is recommended by some as more efficient. Given these efficiencies are measured in sub-milliseconds and that the Apache Commons is a more reliable collection than the java.util collection, the recommendation is to use RandomUtils.

Random conclusion

The failure of many API tests to catch defects prior to release is the limited inputs used to test them. Using random data in conjunction with iterative loops will help lower the amount of time spent patching production issues and leave more time for building business capabilities and value.


Originally published at https://www.logic2020.com/insight/tactical/generate-random-test-data-run-time-jmeter

If you found this interesting, please share.

© Scott S. Nelson