I am have difficulties to implement the REST service for Ticket Creation with OTRS, I already integrate TicketGet and TicketUpdate services with my system, but can't integrate with the TicketCreate service.
yml file:
---
Debugger:
DebugThreshold: debug
TestMode: '0'
Description: Is used by me
FrameworkVersion: 4.0.8
Provider:
Operation:
TicketCreate:
Description: TicketCreate
MappingInbound:
Type: Simple
MappingOutbound:
Config:
KeyMapDefault:
MapTo: ''
MapType: Keep
ValueMapDefault:
MapTo: ''
MapType: Keep
Type: Simple
Type: Ticket::TicketCreate
TicketGet:
Description: TicketGet
MappingInbound:
Type: Simple
MappingOutbound:
Type: Simple
Type: Ticket::TicketGet
TicketUpdate:
Description: TicketUpdate
MappingInbound:
Type: Simple
MappingOutbound:
Type: Simple
Type: Ticket::TicketUpdate
Transport:
Config:
KeepAlive: ''
MaxLength: '20000000'
RouteOperationMapping:
TicketCreate:
RequestMethod:
- POST
Route: /TicketCreate
TicketGet:
Route: /TicketGet/:TicketID
TicketUpdate:
RequestMethod:
- POST
Route: /TicketUpdate/:TicketID
Type: HTTP::REST
RemoteSystem: ''
Requester:
Transport:
Type: HTTP::REST
Request:
{
"UserLogin":"web.service",
"Password":"********",
"Ticket":{
"Title":"Title",
"QueueID":"61",
"LockID":"2",
"TypeID":"1",
"ServiceID":"",
"SLAID":"",
"StateID":"63",
"PriorityID":"3",
"CustomerUser":"user#email.com.br"
},
"Article":{
"ArticleTypeID":"8",
"SenderTypeID":"1",
"From":"User <user#email.com.br>",
"Subject":"WebService Proc Linner Teste",
"Body":"Teste WebService",
"ContentType":"text/plain",
"MimeType":"text/plain",
"Charset":"UTF8"
}
}
Return:
{
"Error":
{
"ErrorCode":"TicketCreate.InvalidParameter",
"ErrorMessage":"TicketCreate: Article->ContentType is invalid!"
}
}
what is a valid ContentType ?
Can someone help me?
Ticket and Article need to be objects at the same level. And, as pointed out by #TOndrej, you're passing some attributes that do not exist for Article. Please find a minimal data sample below:
{
"Ticket" : {
"Queue" : "Raw",
"Priority" : "3 normal",
"CustomerUser" : "max",
"Title" : "REST Create Test",
"State" : "open",
"Type" : "Unclassified"
},
"Article" : {
"ContentType" : "text/plain; charset=utf8",
"Subject" : "Rest Create Test",
"Body" : "This is only a test"
}
}
Related
I have a product model. I reference other products under 'similarProducts'. I dont understand the difference of me having a reference or just embedding data.
const productSchema = new mongoose.Schema({
name: {
type: String
},
hasReport: {
type: Boolean
},
reports: [ReportSchema],
similarProducts: {
name: {
type: [String]
},
id: [{
type: mongoose.Schema.Types.ObjectId,
ref: 'Product'
}]
}
}
mongoose.model('Product', productSchema);
I have added the similar products manually to my db. I have added manually the names and id's of 'other products', now what I see inside my db:
{
"_id" : ObjectId("gdfbhert"),
"name" : "product 1",
"similarProducts" : {
"name" : [
"product 5",
"product 9"
],
"id" : [
"abcde",
"a1b2c3d4"
]
},
"reports" : []
}
I might just not understand how it all works and it might be a stupid question but I just want to understand the impact of having references! In my examle, couldnt I just have embedded the names and id's without stating a reference?!
...
similarProducts: {
name: {
type: [String]
},
id: [String]
}
...
Could someone explain to me the difference? Thank you so much!!
I'm trying to add a GET Response to my API Gateway with AWS CDK.
However, I get this Error when I do cdk deploy:
Invalid mapping expression specified: Validation Result: warnings : [], errors : [Invalid mapping expression parameter specified: method.response.header.Content-Type] (Service: AmazonApiGateway; Status Code: 400; Error Code: BadRequestException; Request ID: f4b6ec17-f0ae-4e2a-aa18-b86ddcac807a; Proxy: null)
My Code:
const admin = api.root.addResource('admin');
admin.addMethod(
'GET',
new apigw.LambdaIntegration(hmtl_code, {
passthroughBehavior: apigw.PassthroughBehavior.WHEN_NO_MATCH,
requestTemplates: { 'application/json': '{"statusCode": 200}' },
integrationResponses: [
{
statusCode: "200",
responseParameters: {
'method.response.header.Content-Type': "'text/html'"
},
responseTemplates: { "text/html": "$input.path('$')" }
}
]
}),
{
methodResponses: [
{
statusCode: "200",
}
]
}
);
I tried it with a MockIntegration as well, but this Error message keeps popping up.
Help would be appreciated, thanks :)
Clearly a bit late here, but I just ran into the same issue and wish the cdk error was clearer.
The parameters in integrationResponses needs to be defined as part of methodResponses too.
From the docs for IntegrationResponse.responseParameters:
The destination must be an existing response parameter in the MethodResponse property.
So applying that to your code...
const admin = api.root.addResource('admin');
admin.addMethod(
'GET',
new apigw.LambdaIntegration(hmtl_code, {
passthroughBehavior: apigw.PassthroughBehavior.WHEN_NO_MATCH,
requestTemplates: { 'application/json': '{"statusCode": 200}' },
integrationResponses: [
{
statusCode: '200',
responseParameters: {
'method.response.header.Content-Type': "'text/html'",
},
responseTemplates: { 'text/html': "$input.path('$')" },
},
],
}),
{
methodResponses: [
{
statusCode: '200',
responseParameters: {
// a required response parameter
'method.response.header.Content-Type': true,
// an optional response parameter
'method.response.header.Content-Length': false,
},
},
],
}
);
I'm trying to build an application with the AWS CDK and if I were to build an application by hand using the AWS Console, I normally would enable CORS in API gateway.
Even though I can export the swagger out of API Gateway and have found numerous options to generate a Mock endpoint for the OPTIONS method I don't see how to do this with the CDK. Currently I was trying:
const apigw = require('#aws-cdk/aws-apigateway');
where:
var api = new apigw.RestApi(this, 'testApi');
and defining the OPTIONS method like:
const testResource = api.root.addResource('testresource');
var mock = new apigw.MockIntegration({
type: "Mock",
methodResponses: [
{
statusCode: "200",
responseParameters : {
"Access-Control-Allow-Headers" : "string",
"Access-Control-Allow-Methods" : "string",
"Access-Control-Allow-Origin" : "string"
}
}
],
integrationResponses: [
{
statusCode: "200",
responseParameters: {
"Access-Control-Allow-Headers" : "'Content-Type,X-Amz-Date,Authorization,X-Api-Key,X-Amz-Security-Token'",
"Access-Control-Allow-Origin" : "'*'",
"Access-Control-Allow-Methods" : "'GET,POST,OPTIONS'"
}
}
],
requestTemplates: {
"application/json": "{\"statusCode\": 200}"
}
});
testResource.addMethod('OPTIONS', mock);
But this doesn't deploy. The error message I get from the cloudformation stack deploy when I run "cdk deploy" is:
Invalid mapping expression specified: Validation Result: warnings : [], errors : [Invalid mapping expression specified: Access-Control-Allow-Origin] (Service: AmazonApiGateway; Status Code: 400; Error Code: BadRequestException;
Ideas?
The recent change has made enabling CORS simpler:
const restApi = new apigw.RestApi(this, `api`, {
defaultCorsPreflightOptions: {
allowOrigins: apigw.Cors.ALL_ORIGINS
}
});
Haven't tested this myself, but based on this answer, it seems like you would need to use a slightly different set of keys when you define your MOCK integration:
const api = new apigw.RestApi(this, 'api');
const method = api.root.addMethod('OPTIONS', new apigw.MockIntegration({
integrationResponses: [
{
statusCode: "200",
responseParameters: {
"method.response.header.Access-Control-Allow-Headers": "'Content-Type,X-Amz-Date,Authorization,X-Api-Key,X-Amz-Security-Token'",
"method.response.header.Access-Control-Allow-Methods": "'GET,POST,OPTIONS'",
"method.response.header.Access-Control-Allow-Origin": "'*'"
},
responseTemplates: {
"application/json": ""
}
}
],
passthroughBehavior: apigw.PassthroughBehavior.Never,
requestTemplates: {
"application/json": "{\"statusCode\": 200}"
},
}));
// since "methodResponses" is not supported by apigw.Method (https://github.com/awslabs/aws-cdk/issues/905)
// we will need to use an escape hatch to override the property
const methodResource = method.findChild('Resource') as apigw.cloudformation.MethodResource;
methodResource.propertyOverrides.methodResponses = [
{
statusCode: '200',
responseModels: {
'application/json': 'Empty'
},
responseParameters: {
'method.response.header.Access-Control-Allow-Headers': true,
'method.response.header.Access-Control-Allow-Methods': true,
'method.response.header.Access-Control-Allow-Origin': true
}
}
]
Would be useful to be able to enable CORS using a more friendly API.
Edit: With updates to CDK it is no longer necessary to use an escape hatch. Please see other answers as they are much cleaner.
Original answer:
This version, originally created by Heitor Vital on github uses only native constructs.
export function addCorsOptions(apiResource: apigateway.IResource) {
apiResource.addMethod('OPTIONS', new apigateway.MockIntegration({
integrationResponses: [{
statusCode: '200',
responseParameters: {
'method.response.header.Access-Control-Allow-Headers': "'Content-Type,X-Amz-Date,Authorization,X-Api-Key,X-Amz-Security-Token,X-Amz-User-Agent'",
'method.response.header.Access-Control-Allow-Origin': "'*'",
'method.response.header.Access-Control-Allow-Credentials': "'false'",
'method.response.header.Access-Control-Allow-Methods': "'OPTIONS,GET,PUT,POST,DELETE'",
},
}],
passthroughBehavior: apigateway.PassthroughBehavior.NEVER,
requestTemplates: {
"application/json": "{\"statusCode\": 200}"
},
}), {
methodResponses: [{
statusCode: '200',
responseParameters: {
'method.response.header.Access-Control-Allow-Headers': true,
'method.response.header.Access-Control-Allow-Methods': true,
'method.response.header.Access-Control-Allow-Credentials': true,
'method.response.header.Access-Control-Allow-Origin': true,
},
}]
})
}
I also ported the same code to python using his version as a guidepost.
def add_cors_options(api_resource):
"""Add response to OPTIONS to enable CORS on an API resource."""
mock = apigateway.MockIntegration(
integration_responses=[{
'statusCode': '200',
'responseParameters': {
'method.response.header.Access-Control-Allow-Headers':
"'Content-Type,\
X-Amz-Date,\
Authorization,\
X-Api-Key,\
X-Amz-Security-Token,X-Amz-User-Agent'",
'method.response.header.Access-Control-Allow-Origin': "'*'",
'method.response.header.Access-Control-Allow-Credentials':
"'false'",
'method.response.header.Access-Control-Allow-Methods':
"'OPTIONS,\
GET,\
PUT,\
POST,\
DELETE'",
}
}],
passthrough_behavior=apigateway.PassthroughBehavior.NEVER,
request_templates={
"application/json": "{\"statusCode\": 200}"
}
)
method_response = apigateway.MethodResponse(
status_code='200',
response_parameters={
'method.response.header.Access-Control-Allow-Headers': True,
'method.response.header.Access-Control-Allow-Methods': True,
'method.response.header.Access-Control-Allow-Credentials': True,
'method.response.header.Access-Control-Allow-Origin': True
}
)
api_resource.add_method(
'OPTIONS',
integration=mock,
method_responses=[method_response]
)
BACKGROUND
I came across this answer while trying to implement the aws_api_gateway_integration_response in Terraform and accidentally came across the solution.
PROBLEM
I was getting this error message:
Invalid mapping expression specified: Validation Result: warnings : [], errors : [Invalid mapping expression specified: POST,GET,OPTIONS]
In the aws_api_gateway_integration_response resource I had the response_parameter key as:
response_parameters = {
"method.response.header.Access-Control-Allow-Headers" = "Content-Type,X-Amz-Date,Authorization,X-Api-Key,X-Amz-Security-Token"
"method.response.header.Access-Control-Allow-Origin" = "*"
"method.response.header.Access-Control-Allow-Methods" = "POST,GET,OPTIONS"
# "method.response.header.Access-Control-Allow-Credentials" = "false"
}
I thought everything was fine as I assumed the double quotes were all that Terraform needed. However, that was not the case.
SOLUTION
I had to add a single quote around the values inside the double quote. Like this:
response_parameters = {
"method.response.header.Access-Control-Allow-Headers" = "'Content-Type,X-Amz-Date,Authorization,X-Api-Key,X-Amz-Security-Token'"
"method.response.header.Access-Control-Allow-Origin" = "'*'"
"method.response.header.Access-Control-Allow-Methods" = "'POST,GET,OPTIONS'"
# "method.response.header.Access-Control-Allow-Credentials" = "false"
}
I'm following a course from mongodb university to learn new features in the release 3.6, and I'm unable to resolve why my validator is invalid.
This is how I created the collection:
db.getSiblingDB("TSA").createCollection("claims", {
validator: {
$jsonSchema: {
bsonType: "object",
properties: {
_id: { },
airportCode: { type: "string", minLength: 3 },
airportName: { type: "string" },
airlineName: { type: "string", minLength: 5 },
claims: {
bsonType: "object",
properties: {
itemCategory: { bsonType: "array", maxItems: 3 },
amount: { type: "string", pattern: "^\$.*" }
}
}
},
required: ["airportCode", "airlineName", "claims"],
additionalProperties: false
}
}
})
Then, I try to insert this object:
db.getSiblingDB("TSA").claims.insertOne({
"airportCode": "ABE",
"airportName": "Lehigh Valley International Airport, Allentown",
"airlineName": "MongoAir",
"claims": {
"claimType": "Property Damage",
"claimSite": "Checked Baggage",
"itemCategory": [ "Sporting Equipment & Supplies" ],
"amount": "$180.00"
}
})
Getting the following error:
WriteError({
"index" : 0,
"code" : 121,
"errmsg" : "Document failed validation",
"op" : {
"_id" : ObjectId("5a705318d3d6c18337f07282"),
"airportCode" : "ABE",
"airportName" : "Lehigh Valley International Airport, Allentown",
"airlineName" : "MongoAir",
"claims" : {
"claimType" : "Property Damage",
"claimSite" : "Checked Baggage",
"itemCategory" : [
"Sporting Equipment & Supplies"
],
"amount" : "$180.00"
}
}
})
My question is, is there some way to debug the validator like "property X must be Y type" instead of getting a generic "Document failed validation"?
As of MongoDB 3.6, there is no feedback mechanism that would inform what part of a document failed validation during a server-side check. A corresponding feature request is open: SERVER-20547: Expose the reason an operation fails document validation. For now, it is left to the application code to perform its own validation if detailed feedback is required.
If you use regex pattern string, backslash itself must be escaped too:
db.getSiblingDB("TSA").createCollection("claims", {
validator: {
$jsonSchema: {
bsonType: "object",
properties: {
_id: { },
airportCode: { type: "string", minLength: 3 },
airportName: { type: "string" },
airlineName: { type: "string", minLength: 5 },
claims: {
bsonType: "object",
properties: {
itemCategory: { bsonType: "array", maxItems: 3 },
amount: { type: "string", pattern: "^\\$.*" }
}
}
},
required: ["airportCode", "airlineName", "claims"],
additionalProperties: false
}
}
})
I created a user in my template with an access key:
"MyAccessKey" : {
"Type" : "AWS::IAM::AccessKey",
"Properties" : {
"UserName" : { "Ref" : "User12" }
}
}
I need to get the access key ID and the secret key in the output of the template. How to do that ?
Thank you
CloudFormation's Outputs documentation states ...
CloudFormation doesn't redact or obfuscate any information you include in the Outputs section. We strongly recommend you don't use this section to output sensitive information, such as passwords or secrets.
A safer option is to create an AWS::SecretsManager::Secret resource that contains the user's access and secret keys.
Here's an example of a template for creating "bot" users that leverages this approach ...
---
AWSTemplateFormatVersion: 2010-09-09
Description: example bot user
Resources:
Bot:
Type: AWS::IAM::User
Properties:
Path: /bot/
UserName: !Ref AWS::StackName
BotCredentials:
Type: AWS::IAM::AccessKey
Properties:
Status: Active
UserName: !Ref Bot
BotCredentialsStored:
Type: AWS::SecretsManager::Secret
Properties:
Name: !Sub /bot/credentials/${Bot}
SecretString: !Sub '{"ACCESS_KEY":"${BotCredentials}","SECRET_KEY":"${BotCredentials.SecretAccessKey}"}'
The access key id and the secret key are available as return values for the AWS::IAM::AccessKey resource:
"Outputs" : {
"MyAccessKeyId": {
"Ref" : "MyAccessKey"
},
"MySecretKey": {
"Fn::GetAtt": [ "MyAccessKey", "SecretAccessKey" ]
}
}