I'll let you in on a not so well kept secret. You can often troubleshot the Trailhead challenge validation in a developer org. But shh, don't tell anyone!
It's really as simple as having the developer console open and actively capturing debug logs when the validation occurs.
I reran the validation for this challenge and got the following logs.
So Trailhead ran two lots of anonymous Apex to validate the challenge. Interesting...
If we drill into the first anonymous Apex class we can see exactly what they are doing. Publishing the event for Order # 105.
Order_Event__e orderEvent = new Order_Event__e(Order_Number__c='105', Has_Shipped__c=true);
Database.SaveResult sr = EventBus.publish(orderEvent);
And then that second call to validate that it worked as expected.
List<Task> tasks = [select id from task where subject = 'Follow up on shipped order 105'];
System.assert(tasks.size() > 0);
delete tasks;
Now we know this, there are two things we could do:
- Create a Task before running the validation with the subject 'Follow up on shipped order 105'
- Further debug your Platform Event to figure out why it isn't meeting those requirements.
While the 1st option may be tempting and easy it doesn't really help you in the long run. What's the point in cheating yourself of the opportunity to learn more in the debugging process.
I'd recommend modifying your Apex test case to replicate the assertions Trailhead is making. You could also look at capturing debug logs for the Platform Events to see what happens when the trigger fires.
For a not so subtle hint. Check your Task subject closely to see if there is anything out of place.
There are some Salesforce Docs on Subscribe to and Replay Events Using a Visualforce Page. They seem like a good place to start.
Here I'll replicate that example, except from sfdx.
sfdx force:project:create --projectname cometd
cd cometd
mkdir mdapipkg
git clone https://github.com/developerforce/SalesforceDurableStreamingDemo.git mdapipkg
Remove the mdapipkg\.git
folder
sfdx force:mdapi:convert --rootdir mdapipkg
sfdx force:org:create -f config\project-scratch-def.json -a cometd
sfdx force:org:open -u cometd
Alter the file force-app\main\default\applications\Durable_Streaming_Demo.app-meta.xml to remove the two tab
elements and replace then with tabs
.
<?xml version="1.0" encoding="UTF-8"?>
<CustomApplication xmlns="http://soap.sforce.com/2006/04/metadata">
<defaultLandingTab>standard-home</defaultLandingTab>
<isNavAutoTempTabsDisabled>false</isNavAutoTempTabsDisabled>
<isNavPersonalizationDisabled>false</isNavPersonalizationDisabled>
<label>Durable Streaming Demo</label>
<tabs>DurablePushTopicStreamingDemo</tabs>
<tabs>DurableGenericStreamingDemo</tabs>
</CustomApplication>
Push the source to the scratch org and configure:
sfdx force:source:push -u cometd
sfdx force:user:permset:assign --permsetname DurableStreamingDemo --targetusername cometd
If I go to the Durable PushTopic Streaming Demo tab in the UI I can see cometD notifications coming into the Visualforce page.
The cometD subscription is actually occurring in DurablePushTopicEventDisplay.component
.
I haven't compared their code to yours in great depth, but something that stands out is how the authentication is handled.
In their code they have:
// Connect to the CometD endpoint
cometd.configure({
url: window.location.protocol+'//'+window.location.hostname+ (null != window.location.port ? (':'+window.location.port) : '') +'/cometd/37.0/',
requestHeaders: { Authorization: 'OAuth {!$Api.Session_ID}'}
});
In comparison, your sample code does the equivalent in the init
call. This may or may not be significant.
Another difference here is that the sample code is locked at API v37.0 and you are trying to use v44.0. I know this was historically an issue with the developer console, which is still using v36.0.
Check that you are using v3.1.0 of CometD. See Supported CometD Versions
Changing the demo to work with Platform Events rather than PushTopics.
According to Subscribe to Platform Event Notifications with CometD we want the channel to be
/event/EPlatformEvent__e
This should be changed in DurablePushTopicStreamingController.cls
Change line 3 to:
private static final String TOPIC_NAME = 'EPlatformEvent__e';
And line 10 to use /event/
rather than /topic/
.
this.channel = '/event/' + TOPIC_NAME;
We should probably do something with getOrCreatePushChannel()
as the PushTopic isn't required anymore, but for now I've left it as is.
Push these changes to your scratch org then publish a new Platform Event.
EPlatformEvent__e testEvent = new EPlatformEvent__e();
EventBus.publish(testEvent);
Best Answer
Unfortunately, you can't do it.
Because Community Users don't have access to Push Topics (idea), related question. And Platform Event, Data Change Event are built on Push Topics.
I have a similar use case where I need to use functionality in both Community and Internal, so I had to use different implementations based on the running environment.
UPDATE: actually you can answer