I'm using aws-flow to interact with Amazon's Simple Workflow Server and I want to get logging set up to go to an external source (PaperTrail).
I've set my $logger to use PaperTrail and I pass this into the client I use to start the execution;
client = Aws::SWF::Client.new(region: 'eu-west-1', logger: $logger)
client.start_workflow_execution({
domain: domain,
workflow_id: ...,
workflow_type: {
name: "...",
version: ...
},
task_list: {
name: "..."
}
})
This successfully logs that the client has started, but no action from inside a Workflow or Activity gets logged.
From reading the documentation and this SO answer it seems like you need to specify a logger when creating new Activities, but I can't see how to do that.
The main workflow uses activity_client to select the Activitiy it needs, and the activity being called looks like;
class MyActivity
extend AWS::Flow::Activities
activity :my_activity do {
default_task_list: '...',
version: ...,
default_task_schedule_to_start_timeout: 60,
default_task_start_to_close_timeout: 60,
exponential_retry: { maximum_attempts: 2 }
}
I can't see anywhere with this setup that you can add a logger to.
Any help would be greatly appreciated
So it turns out aws-flow doesn't support logging.
There is some chat about it in issues and there is a PR which appears to fix things.
For my needs I just forked the project (which at the time of writing hasn't been updated in 2 years) and made the relevant changes for me.
Related
as you know, the documentation indicates tha we need a javascipt like this:
Checkout.configure({
session: {
id: '<your_create_checkout_session_ID>'
},
interaction: {
merchant: {
name: 'Your merchant name',
address: {
line1: '200 Sample St',
line2: '1234 Example Town'
}
}
}
});
, as it is javascript in an HTML, everyone can see our Merchant_id and the session_id,etc.
How can we hide this info ??
thanks
In my opinion, you shouldn't use this type of information and configuration in your Front-end application/client because of the security issue that you mentioned.
Instead of that, use these steps:
remove all implementation like configuration, checkout, double-check payments, etc. from your client.
implement them into your backend-application / server (as a service or microservice)
use the usual REST API to communicate between your client and server applications
hope to be useful in your case.
I did the following:
https://hyperledger.github.io/composer/business-network/publishing-events.html
https://hyperledger.github.io/composer/applications/subscribing-to-events.html
The docs make it seem like this is all you need to stick in your Node.js server:
businessNetworkConnection.on('event', (event) => {
// event: { "$class": "org.namespace.BasicEvent", "eventId": "0000-0000-0000-000000#0" }
console.log(event);
});
But nothing is happening in my case. I can see my transactions emitting events through the playground UI, but they aren't hitting my Node.js server.
Do I have to set up my own websocket server or something?
So
Emit your events in your TP code (and you've done this) - example -> https://github.com/hyperledger/composer-sample-networks/blob/master/packages/trade-network/lib/logic.js#L28 or as shown at https://hyperledger.github.io/composer/business-network/publishing-events.html
Have defined the Event class in your model file - eg -> https://github.com/hyperledger/composer-sample-networks/blob/master/packages/trade-network/models/trading.cto#L25 - then updated to the runtime business network that you previously deployed using composer network update
The eventId property in event is always the same as the transactionId of the transaction which emitted the event.
I am trying to set up streaming from an Azure VM scale set to an event hub via Diagnostics configuration.
I have my public config which includes the SinksConfig as follows (I have omitted the rest of the config for the sake of brevity):
{
"WadCfg": {
"DiagnosticMonitorConfiguration": {
*** config for performance counters and ETW ***
"SinksConfig": {
"Sink": [
{
"name": "eventhub",
"EventHub": {
"Url": "sb://myhub.servicebus.windows.net/mycompanyapplication",
"SharedAccessKeyName": "RootManageSharedAccessKey"
}
}
]
}
},
"StorageAccount": "<storageaccount>"
}
and the private config:
{
"storageAccountName": "<storageaccountname>",
"storageAccountKey": "<storageaccountkey>",
"storageAccountEndPoint": "https://core.windows.net",
"EventHub": {
"Url": "sb://myhub.servicebus.windows.net/mycompanyapplication",
"SharedAccessKeyName": "RootManageSharedAccessKey",
"SharedAccessKey": "<sharedaccesskey>"
}
}
However, nothing is being received by the event hub. I can see in the storage account logs that the Diagnostics extension is running:
but in the substatus there are many errors around the SAS key and the event hub:
When I check back in the Visual Studio Diagnostics configuration on the Scale set I see this error:
I have checked the naming convention on the SharedAccessKeyName (which is the default provided when the event hub was set up) know that the SAS key works as I wrote a console app to send messages to the same event hub with the same credentials and it worked fine.
So there is obviously a problem with the authentication to the event hub as it can't read the access key from the config file. However, I can't see any other way of providing it.
Am I missing something obvious here in my config?
Turns out the problem was quite simple, I had grabbed the URL from the connection string in the portal which was
sb://myhub.servicebus.windows.net/mycompanyapplication
when it should have been
https://myhub.servicebus.windows.net/mycompanyapplication
Now the data is flowing freely into the event hub.
However, the diagnostics config in VS still shows the warning about not being able to read the SAS key, which now looks like a "red herring" that ended up costing me a lot of time :(
I'm trying to use express-stormpath on my Heroku app. I'm following the docs here, and my code is super simple:
var express = require('express');
var app = express();
var stormpath = require('express-stormpath');
app.use(stormpath.init(app, {
website: true
}));
app.on('stormpath.ready', function() {
app.listen(3000);
});
I've already looked at this question and followed the Heroku devcenter docs. The docs say that for an Heroku app, it's not necessary to pass in options, but I've still tried passing in options and nothing works. For example, I've tried this:
app.use(stormpath.init(app, {
// client: {
// file: './xxx.properties'
// },
client: {
apiKey: {
file: './xxx.properties',
id: process.env.STORMPATH_API_KEY_ID || 'xxx',
secret: process.env.STORMPATH_API_KEY_SECRET || 'xxx'
}
},
application: {
href: 'https://api.stormpath.com/v1/applications/blah'
},
}));
To try and see what's going on, I added a console.log line to the stormpath-config strategy valdiator to print the client object, and it gives me this:
{ file: './apiKey-xxx.properties',
id: 'xxx',
secret: 'xxx' }
{ file: null, id: null, secret: null }
Error: API key ID and secret is required.
Why is it getting called twice, and the second time around, why does the client object have null values for the file, id and secret?
When I run heroku config | grep STORMPATH, I get
STORMPATH_API_KEY_ID: xxxx
STORMPATH_API_KEY_SECRET: xxxx
STORMPATH_URL: https://api.stormpath.com/v1/applications/[myappurl]
I'm the original author of the express-stormpath library, and also wrote the Heroku documentation for Stormpath.
This is 100% my fault, and is a documentation / configuration bug on Stormpath's side of things.
Back in the day, all of our libraries looked for several environment variables by default:
STORMPATH_URL (your Application URL)
STORMPATH_API_KEY_ID
STORMPATH_API_KEY_SECRET
However, a while ago, we started upgrading our libraries, and realized that we wanted to go with a more standard approach across all of our supported languages / frameworks / etc. In order to make things more explicit, we essentially renamed the variables we look for by default, to:
STORMPATH_APPLICATION_HREF
STORMPATH_CLIENT_APIKEY_ID
STORMPATH_CLIENT_APIKEY_SECRET
Unfortunately, we did not yet update our Heroku integration or documentation to reflect these changes, which is why you just ran into this nasty issue.
I just submitted a ticket to our Engineering team to fix the names of the variables that our Heroku addon provisions by default to include our new ones, and I'm going to be updating our Heroku documentation later this afternoon to fix this for anyone else in the future.
I'm sincerely sorry about all the confusion / frustration. Sometimes these things slip through the cracks, and experiences like this make me realize we need better testing in place to catch this stuff earlier.
I'll be working on some changes internally to make sure we have a better process around rolling out updates like this one.
If you want a free Stormpath t-shirt, hit me up and I'll get one shipped out to you as a small way to say 'thanks' for putting up with the annoyance: randall#stormpath.com
After endless hours, I managed to finally get it working by removing the add-on entirely and re-installing it via the Heroku CLI and then exporting variables STORMPATH_CLIENT_APIKEY_ID and STORMPATH_CLIENT_APIKEY_SECRET. For some reason, installing it via the Heroku Dashboard causes express-stormpath to not find the apiKey and secret fields (even if you export variables).
I was wondering if anyone has seen a demo/example of using the Serilog.Extras.MSOwin package with a web api project or a example/tutorial of using Serilog with a web api project.
Any help greatly appreciated,
Jim
I will take this as question as "How do I used Serilog.Extras.MSOwin?" and given it is currently a rather small library answer here.
This reflects the current library (1.4.102) and is subject to change in the future.
Serilog.Extras.MSOwin provides two things: a Microsoft.Owin.Logging.ILoggerFactory implementation to have OWIN's logging infrastructure write to Serilog (more details about logging in OWIN in this blog post) and Guid identifier (RequestId) for each web request to aid in associating logged events.
The Logging integration is done with the following:
IAppBuilder app = ...;
Serilog.ILogger logger = ...'
app.SetLoggerFactory( new Serilog.Extras.MSOwin.LoggerFactory( logger ) );
The request id functionality needs to be registered in the OWIN pipeline:
IAppBuilder app = ...;
app.UseSerilogRequestContext("RequestId");
You will want to register that very early in the pipeline because any logging occurring before that pipeline step will not have the request id available.
You also need will need to retrieve it from the LogContext using Enrich.FromLogContext() and add that property to what you write to your sinks. For example,
const string DefaultOutputTemplate =
"{Timestamp:yyyy-MM-dd HH:mm:ss.fff zzz} ({RequestId}) {Message}{NewLine}{Exception}";
ILogger logger =
new LoggerConfiguration().Enrich.FromLogContext()
.WriteTo
.RollingFile(
"log.txt",
outputTemplate: DefaultOutputTemplate)
.CreateLogger();
Serilog.Extras.MSOwin was superseded by SerilogWeb.Owin (which has since also been discontinued.)