Open barkalinowski opened 1 year ago
Hello Bartosz, It was a temporary issue that appeared due to a major version upgrade on Onenet last week. It is fixed now. Everything works ok now.
Hi Helias,
We have checked it and it is still not working. This time we have problems with lacking permission to perform consume or provide data:
Maybe our accounts are somehow blocked?
Hello again,
It seems like we have managed to fix issue with providing data, but now we have problem with consuming data. Here is log file: docker_be-dataapp-consumer_1-2023-06-14T08-03-56.log
Could you please check it?
Hello again,
It seems like we have managed to fix issue with providing data, but now we have problem with consuming data. Here is log file: docker_be-dataapp-consumer_1-2023-06-14T08-03-56.log
Could you please check it?
Hi, it seems related to the conversion of the data into the Orion Context Broker data model.
Which kind of data are you providing?
Can you please test a new entire workflow (create service, create data, subscribe and get)?
Thanks, Ferdinando
Hi,
thank you for your reply - I have tested new entire workflow and again the same error and problem. Log file does not change. Are there any other things we can check?
Hello again,
theoretically providing and consuming data works for us right now, but we cannot download shared files. In logs we have this error:
I would like to ask you about verification of this error.
Additionally we would like to ask, why "content" field is missing in this response and what is the cause of this situation:
Also full log file can be found here: flex-docker-onenet.log
Hello, can you provide us with more information ? If I understand right you are able to upload a file and you can downloaded but you can consume data from other users. If this is the case: 1) confirm that your connection settings are right (in the dashboard there is a connection checker -> should be green) 2) give us information about the file that you try to download (user, offered service and specific file) . Maybe some users have some changes in their installation and you come up with this issue. Best regards, Christos
Hello Christos,
If kamil.starzewski provides data, for bartosz.kalinowski to consume, the same error is happening.
Hello again , the file that you send me as an example is created by you. So I want to ask if you are able to downloaded for your own . If one of you can not download his own files the problem maybe is relevant to this user. If both of you can download your own files you need to check for network issues. (Try to exchange a file when you are in the same network or ensure that data app and ecc url are public and mapped to static ip for both users) Also I have added a request for this offered service as tteesstt user to see if I can consume it. Thank you , Christos
Hi Christos, I have accepted your request, try to consume data. I have also tried to download a file as bartosz.kalinowski(which was the provider) and I also cannot do it. So provider cannot download the file, which he provided and consumer cannot download a provided file. What can we do about it?
Regarding network issues I am quite sure, everything is sorted out on our side. Every IP used is static and open to public, we confirmed this with Helias, Ferdinando and Vassilis some time ago. Both accounts (bartosz.kalinowski and kamil.starzewski) use the same configuration of connection also.
Can you make a last check please ? Can you check if all the containers are up and running correctly ? Thank you in advance, Christos
Sure Christos, here you go:
Hi @christos-aslamatzidis are there any new updates what can we do about our problem?
Hi Bartosz, we investigated in the logs and we found the following:
284: [35mecc-consumer_1 |[0m 12-07-2023 11:31:57.917 [qtp1121373774-85] INFO it.eng.idsa.businesslogic.service.impl.SendDataToBusinessLogicServiceImpl.sendMessageFormData - Forwarding Message: Body: form-data
Riga 285: [35mecc-consumer_1 |[0m 12-07-2023 11:31:58.113 [qtp1121373774-85] INFO it.eng.idsa.businesslogic.service.impl.SendDataToBusinessLogicServiceImpl.checkResponse - status code of the response message is: 404
Riga 286: [35mecc-consumer_1 |[0m 12-07-2023 11:31:58.114 [qtp1121373774-85] INFO it.eng.idsa.businesslogic.service.impl.SendDataToBusinessLogicServiceImpl.checkResponse - ...communication error - bad forwardTo URL https://atflex-ecc-onenet.tt-cloud.com.pl/data
Riga 287: [35mecc-consumer_1 |[0m 12-07-2023 11:31:58.115 [qtp1121373774-85] INFO it.eng.idsa.businesslogic.service.impl.RejectionMessageServiceImpl.sendRejectionMessage - Creating rejection message of type REJECTION_COMMUNICATION_LOCAL_ISSUES
It seems an issue related to the communication between the two ECC of the connectors (provider and consumer). Are you using a unique connector? Are ecc-provider and ecc-consumer on the same VM? Please check if the ecc-provider url is correctly setup. Try https://ecc-provider:8889/data
Hi Ferdinando,
well, yes both of the users(provider and consumer) are configured on the same VM and have the same connetor settings. Is this correct or this the cause of our problems?
Also how are we suppose to check if we use unique connector? You mean unique for each of the user? And how we can check if ecc-provider url is correctly setup?
Here is our setup of the connector settings(for both users is the same):
First three urls are public domains connected through proxy to VM, which IP address is in the last url, and every docker container is installed on this VM.
Hi again, you can use the same connector with two different users. No problem with that.
We have done some additional tests. It seems that ECC is not reachable. We receive a 403 forbidden. It looks like it requires authentication or something, but it shouldn't be.
Hi Ferdinando,
Thank you for your response. I would like to ask you what should we expect from this request? We were trying on our side, internally and here are our observations:
Hi,
at the 8889 you should receive a Jetty error like this:
With /data, you should download a JSON like this:
--AyivDgLGvyZ-0mrbPbgiUorzq0vAsIk4w
Content-Disposition: form-data; name="header"
Content-Length: 1204
Content-Type: application/ld+json
{
"@context" : {
"ids" : "https://w3id.org/idsa/core/",
"idsc" : "https://w3id.org/idsa/code/"
},
"@type" : "ids:RejectionMessage",
"@id" : "https://w3id.org/idsa/autogen/rejectionMessage/8fd1eeeb-d7f6-490f-b5f1-26790431914a",
"ids:rejectionReason" : {
"@id" : "https://w3id.org/idsa/code/MALFORMED_MESSAGE"
},
"ids:issuerConnector" : {
"@id" : "https://w3id.org/engrd/connector/"
},
"ids:recipientConnector" : [ {
"@id" : "http://w3id.org/engrd/connector"
} ],
"ids:senderAgent" : {
"@id" : "https://w3id.org/engrd/connector/"
},
"ids:recipientAgent" : [ ],
"ids:securityToken" : {
"@type" : "ids:DynamicAttributeToken",
"@id" : "https://w3id.org/idsa/autogen/dynamicAttributeToken/a6a38918-80bc-4364-bcc0-b5eaaeb50b8e",
"ids:tokenFormat" : {
"@id" : "https://w3id.org/idsa/code/JWT"
},
"ids:tokenValue" : "DummyTokenValue"
},
"ids:modelVersion" : "4.1.0",
"ids:issued" : {
"@value" : "2023-07-24T15:11:24.819Z",
"@type" : "http://www.w3.org/2001/XMLSchema#dateTimeStamp"
},
"ids:correlationMessage" : {
"@id" : "https://w3id.org/idsa/autogen/rejectionMessage/3b16bb99-f96a-4d0b-b06e-e7fe5f49f290"
}
}
--AyivDgLGvyZ-0mrbPbgiUorzq0vAsIk4w--
Hi Ferdinando,
we have managed to fix 8889 port and we get exactly what you indicated in the previous post(we get Jetty error and after addition of "/data" we download JSON file). Unfortunately it did not solve our problems regarding consumption of the data. We get exactly the same error as previously. It turned out that proxy was trying to connect to docker through 8889 with http - that was causing the problem. So we changed also from http to https for local api and data app ports, but it switched off our connection, so we came back to http connection for these two. What can be our next steps regarding this case?
Hi Ferdinando,
I would like to remind you about problems we have. We still get 500:
Hi,
we managed to establish connection with onenet system:
We were able to do that by making Local API url public.
Although we are not able to consume or provide data through the GUI.
Here is our request for providing data:
and here is response from the connector:
Very similar errors we get when we try to consume data. Is it something on your side or do we still do something wrong?