I'm tring to use trust wallet core in c++ and sign a tron transaction but I got TaPos error.
I need change Transaction reference block from "head" to "solid".
how can do it?
Transaction reference block, default is "head", configure to "solid" can avoid TaPos error
I resolved it, The problem not related to "Transaction reference block".
For broadcast must latest block of chain info set to block header in tron blockchian.
This api give latest block info(In testnet):
GET Api: https://api.nileex.io/wallet/getnowblock
Related
I am getting some attributes in an API but all getting lost after an HTTP request connector in mule4.
why is it happening?
Look in the connector's configuration properties -> advanced tab for the connector configuration (in this case the HTTP connector's "request" operation) and you'll find a target variable and target value. If you fill in the target with a name - this does an enrichment to avoid overwriting the Mule message. If you leave it blank (the default) it will save the message (attributes, payload) over the top of the existing one - which is what you're seeing now. This mirrors the old mule 3 functionality, but sometimes you want it to leave what you have there alone.
So for the target value you get to pick exactly what gets saved.. If you want just payload: put that in. If you want both payload and attributes - I'd use "message" as that will mean you get both payload and attributes saved in the variable. Of course you may not want as much saved, so feel free to put in whatever dataweave expression you like - so you could even create something with bits from anywhere like:
{
statusCode: attributes.statusCode,
headers: attributes.headers,
payload: payload
}
A connector operation may replace the attributes with those of the operation. If you need to preserve the previous attributes you need to save them to a variable.
This is a default behaviour of MuleSoft. Whenever request crosses to transport barrier it losses existing attributes. You need to preserve attribute before HTTP Request.
From the Apigility documentation (Error Reporting):
The API Problem specification allows you to compose any other additional fields that you feel would help further clarify the problem and why it occurred. Apigility uses this fact to provide more information in several ways:
Validation error messages are reported via a validation_messages key.
When the display_exceptions view configuration setting is enabled, stack traces are included via trace and exception_stack properties.
I don't understand this part of the docu. What is the purpose and how to use the settings validation_messages and display_exceptions?
The display_exceptions setting is from ZF2's view manager (see docs here). Turning this on will cause Apigiltiy to include a stack trace with any error response.
In Apigility itself the validation_messages key population is handled automatically. You configure an input filter which validates the incoming data payload and if the input filter fails the error messages it returns are automatically injected into the API response under the validation_messages key. This functionality is provided by the module zf-content-validation. You can "do it yourself" by returning an ApiProblemResponse from your resource like so:
return new ApiProblemResponse(
new ApiProblem(422, 'Failed Validation', null, null, array(
'validation_messages' => [ /* array of messages */ ]
))
);
Im new on Mule ESB and i have the next problem. I use connector "Collection Splitter" to separate a list of orders (books) to other things. When i do the checks i go back to join the books on the order with connector "Collection Agreggator". What i want is save the information of the payload in that moment in a session variable. The system dont do that. I think is posible because the type saves on the payload is "CopyOnWriteArrayList" type and i dont now if is posible save this type of list in a session variable.
Someone can be help me please?
Thanks!
You can also use a set-session-variable transformer. Set the name is something of your choosing and set the value to be #[payload]. That you will maintain both your payload and have a new session variable. However be very careful when using session variables, since these are serialized when sending a Mule message over a transport. If possible, try to use flow variables.
use the message enricher scope to achieve the same.
define the required component inside the message enricher scope.
in the enricher scope specify source as payload and the target as session variable.
try and let me know the status.
I want to set shipping method using "cart_shipping.method" but it's giving me fetal error. Error message is "Uncaught SoapFault exception: [1062] Shipping method is not available". I am using method like that
$result = $proxy->call($sessionId, 'cart_shipping.method', array(1402,'flatrate'));
I had the same problem because I was using test information which was not valid in the address call (cart_customer.addresses (SOAP V1) or shoppingCartCustomerAddresses (SOAP V2)).
So try a valid address which also works in the front end. For example, if you use the wrong country, magento will probably think: shipping is not available for this country. And then throw the 1062 error you experienced.
Maybe you had the same problem.
(btw I am using this as an example: https://magento.stackexchange.com/questions/6424/how-to-create-order-using-magento-web-services-in-php)
I have a question regarding to Nest1.0pr and the connection error handling. In the previous versions of Nest I was using IResponse.ConnectionStatus.Error. It seems to me that the property Error does not exist in the new version anymore. However in the documentation I found the following:
ConnectionStatus is the response as it was returned by
Elasticsearch.net. It's section on handling responses applies here as
well.
And in the very section the property Error is mentioned.
Error When a call succeeds but does not return a http status code of
200 this property will have details on the error. Read more about
error handling here
So is the recommended way to check whether the property Success is false?
TIA
This changed when NEST was refactored to use Elasticsearch.Net. Now when a request fails, you can try checking the IResponse.ConnectionStatus.OriginalException property, which will contain the actual Elasticsearch error.