Getting below error while reading EDI 837 file using X12 connector(using default config).
Schema: 005010
Version identifier suffix: X222A1
Errors=[X12Error(1,,true,INTERCHANGE_NOTE,025,Duplicate Interchange Control Number,INTERCHANGE_LEVEL,261478,-1,,Duplicate interchange control number 261478)]
Runtime: 4.3
Below config xml
<file:config name="File_Config" doc:name="File Config" doc:id="8542781c-f67d-4d79-9648-b2d15ab37b0c" />
<x12:config name="X12_EDI_Config" doc:name="X12 EDI Config" doc:id="bbe0ec79-d418-41d0-a8b2-4c154b0428b2" versionIdentifierSuffix="X222A1">
<x12:schemas >
<x12:schema value="/x12/005010/837.esl" />
</x12:schemas>
</x12:config>
<flow name="ediFlow" doc:id="70290c60-1e47-43e1-b759-144cbbf24716" >
<file:listener doc:name="On New or Updated File" doc:id="777e4c99-b633-426b-b94e-1e7f4d7190b2" autoDelete="true" config-ref="File_Config" directory="C:\test">
<scheduling-strategy >
<fixed-frequency />
</scheduling-strategy>
</file:listener>
<x12:read doc:name="Read" doc:id="9deb24c2-97c0-438e-a8f7-f88416164b67" config-ref="X12_EDI_Config" target="edidata"/>
<logger level="INFO" doc:name="Logger" doc:id="6969a6c5-9918-42f2-96b7-14e74684c422" message="EDI 837 file: #[vars.edidata]"/>
</flow>
</mule>
It seems that the data contains duplicated Interchange Control Number. By default the connector will raise an error if that happens. If you want to ignore duplicates set in the configuration of the connector "Require unique interchanges" to false. The documentation of this configuration says:
Require unique Interchange Control Numbers (ISA13) for received
interchanges. The normal behavior is to record the interchange numbers
previously processed and reject any duplicate interchange numbers from
the same partner (as determined by the interchange sender and receiver
identification). If false, this instead allows processing of the
received interchange to continue and leaves it to the application flow
to track numbers and handle appropriately.
Related
I am trying to build a UI based in Angular to retrieve all existing execution lists of Tosca. However, I could not find a REST API that can give the list of folders within a workspace in Tosca. Has anyone tried this route?
You can use the Search task on the projectto find all ExecutionLists.
Example:
{rest_url}/ToscaCommander/{workspace_name}/object/project/task/Search
as a post request with the xml payload:
<Parameters xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
<Parameter>
<Name>tqlString</Name>
<Type i:nil="true"/>
<Value>->SUBPARTS:TCFolder[Name=?"Execution"]=>SUBPARTS:ExecutionList</Value>
</Parameter>
</Parameters>
This will give you a list of object ids of the ExecustionLists contained in the Execution folder of the project. You can fetch the objects one by one with this request afterwards:
{rest_url}/ToscaCommander/{workspace_name}/object/{object_id}
Credits for this solution go to the development team of ToscaCommander - they provided it.
P.S.: as an answer for your comment:
Yes, there is a json equivalent of the body - but you do not need it. Anyway, here is the equivalent:
[{
"Name":"tqlString",
"Value":"->SUBPARTS:TCFolder[Name=?\"Execution\"]=>SUBPARTS:ExecutionList"
}]
If you want to get a json response (regardless of the request's payload's format) make sure your web.config sets AutomaticFormatSelectionEnabled to true (which should be the case). Then, in your requests, set the accept header accordingly:
Accept: application/json
I've created a bucket where policy makes it mandatory to specify the content-type of the object being uploaded. If I specify the content-type after file element, (example below)
<form action="..">
...
<input type='file' name='file' />
<input name='content-type' value='image/jpeg' />
<input type='submit' />
</form>
it returns following error
<Error>
<Code>AccessDenied</Code>
<Message>Invalid according to Policy: Policy Condition failed: ["starts-with", "$Content-Type", ""]</Message>
<RequestId>15063EB427B4A469</RequestId>
<HostId>yEzAPF4Z2inaafhcqyQ4ooLVKdwnsrwqQhnYg6jm5hPQWSOLtPTuk0t9hn+zkBEbk+rP4S5Nfvs=</HostId>
</Error>
If I specify content-type before file element, upload works as expected. I encountered this behaviour for the first time. I have a few questions regarding it.
Is it part of some specification where clients and all intermediate proxies are supposed to maintain order of http post params? Please point me to it.
Why would you make your API be aware of such ordering? In this particular case I can guess that the file can be huge and unless you are seeing all expected params before, you should immediately return failure. Please correct me if my understanding is not correct.
It is part of the spec that the parts are sent as ordered in the form. There is no reason to believe that reordering by an intermediate proxy would be allowed.
The form data and boundaries (excluding the contents of the file) cannot exceed 20K.
...
The file or content must be the last field in the form.
http://docs.aws.amazon.com/AmazonS3/latest/API/sigv4-HTTPPOSTForms.html#sigv4-HTTPPOSTFormFields
The logical assumption is that this design allows S3 to reject invalid uploads early.
Hi I want to add a query parameter Age = 23
I tried adding
message.inboundProperties.'http.query.params'.Age = '23'
In a expression
<expression-component doc:name="Expression"><![CDATA[message.inboundProperties.'http.query.params'.Age= '23';]]></expression-component>
It won't work.
Inbound properties are Immutable hence you must add it in outbound property to add a query param in your outbound http connector you can use the below
<http:request config-ref="HTTP_Request_Configuration" path="outway" method="POST" doc:name="HTTP">
<http:request-builder>
<http:query-param paramName="Age" value="23"/>
</http:request-builder>
</http:request>
To add properties to an outgoing message they need to be in the outbound scope:
message.outboundProperties.'http.query.params'.Age= '23'
You are trying to modify inbound properties but you can´t, they are inmutable
Properties have two main scopes: inbound and outbound.
Inbound properties are immutable, are automatically generated by the message source and cannot be set or manipulated by the user. They contain metadata specific to the message source that prevents scrambling of data formats or other processing mishaps later in the message’s lifecycle. A message retains its inbound properties only for the duration of the flow; when a message passes out of a flow, its inbound properties do not follow it (see image below).
https://docs.mulesoft.com/mule-fundamentals/v/3.7/mule-message-structure
You must add it to outbound as Ryan said.
The response fragment below is part of a PROPFIND reply:
<D:response>
<D:href>https://dav.mystery-meat.com/top</D:href>
<D:propstat>
<D:prop>
<D:creationdate ns0:dt="dateTime.tz">1970-01-01T00:00:00Z</D:creationdate>
<D:getcontentlanguage>en</D:getcontentlanguage>
<D:getcontentlength>16384</D:getcontentlength>
<D:getcontenttype>httpd/unix-directory</D:getcontenttype>
<D:getlastmodified ns0:dt="dateTime.rfc1123">Thu, 01 Jan 1970 00:00:00 GMT</D:getlastmodified>
<D:resourcetype><D:collection/></D:resourcetype>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
The getcontentlength value isn't the total bytes of items within this directory. Is there any predefined meaning for this value in WebDAV or is it simply implementor-defined by each server that happens to report a value?
I.e. is it of any real use?
Read the RFC, as usual it has a perfect definition:
Purpose: Contains the Content-Length header returned by a GET without accept headers.
If that isn't clear, it basically says, if you perform a GET request on the same resource with no Accept-* headers, the response will report a Content-Length that is this value.
So if you have a WebDAV implementation that conforms to the standard, you should be able to easily test this by just executing a GET request on the collection. Chances are you'll get some automatically generated HTML response.
If the response to this GET request is a different size (in bytes) as it reported via {DAV:}getcontentlength, it should be considered a bug.
I think in your particular case it might be a bug. The fact that the reported size for the collection is exactly a power of two, leads me to believe that this particular server returns the result of stat() for that directory, which is simply how much space the directory listing takes up on the filesystem (the same number as when you use ls).
If my hunch is true, the server basically has broken behavior.
I am trying to achieve the functionality where i have to call two different backends / target endpoints that have completely different interface in a sequence. Output of one call becomes input to the second one upon an error condition from the first call.
I would like to know how to implement this. I am new to Apigee so details will help me.
It sounds like you need to do a ServiceCallout in the request flow.
Set up your Target as whatever the second server is that you need to talk to in the normal flow. Then create a policy to callout to your first target:
<ServiceCallout name="myPolicy">
<Request clearPayload="false" variable="myRequest"/>
<Response>myResponse</Response>
<HTTPTargetConnection>
<Properties/>
<URL>http://example.com</URL>
</HTTPTargetConnection>
</ServiceCallout>
Note the Response block puts the headers and payload from the response into an object that you can then extract variables from using "myResponse" as the <Source> in the ExtractVariables policy.
Then you can build a new request for your target with the variables you set in the ExtractVariables by using an AssignMessage policy
Service Callout
http://apigee.com/docs/api-services/content/call-services-or-apis-using-servicecallout
ExtractVariables
http://apigee.com/docs/api-services/content/extract-message-content-using-extractvariables
AssignMessage
http://apigee.com/docs/api-services/content/generate-or-modify-messages-using-assignmessage