search

european-dynamics-rnd / OneNet

8 stars 1 forks source link

Cannot provide and consume data #16

Open barkalinowski opened 1 year ago

barkalinowski commented 1 year ago

Hi,

we managed to establish connection with onenet system: image 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: image and here is response from the connector: image Very similar errors we get when we try to consume data. Is it something on your side or do we still do something wrong?

HeliasEurodyn commented 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.

barkalinowski commented 1 year ago

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: image image

Maybe our accounts are somehow blocked?

barkalinowski commented 1 year ago

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?

ferdinandobosco commented 1 year ago

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

barkalinowski commented 1 year ago

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?

barkalinowski commented 1 year ago

Hello again,

theoretically providing and consuming data works for us right now, but we cannot download shared files. In logs we have this error: image

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: image

Also full log file can be found here: flex-docker-onenet.log

christos-aslamatzidis commented 1 year ago

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

barkalinowski commented 1 year ago

Hello Christos,

  1. Yes, we have established connection: image
  2. Example file: user: kamil.starzewski offered service: 3c1fe571-4381-492a-99f3-a1479b940cd8 file: aee04a31-173b-40b6-9064-c70c1e7c0a1d

If kamil.starzewski provides data, for bartosz.kalinowski to consume, the same error is happening.

christos-aslamatzidis commented 1 year ago

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

barkalinowski commented 1 year ago

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.

christos-aslamatzidis commented 1 year ago

Can you make a last check please ? Can you check if all the containers are up and running correctly ? Thank you in advance, Christos

barkalinowski commented 1 year ago

Sure Christos, here you go: image

barkalinowski commented 1 year ago

Hi @christos-aslamatzidis are there any new updates what can we do about our problem?

ferdinandobosco commented 1 year ago

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

barkalinowski commented 1 year ago

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): image 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.

ferdinandobosco commented 1 year ago

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.

MicrosoftTeams-image

barkalinowski commented 1 year ago

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:

ferdinandobosco commented 1 year ago

Hi, at the 8889 you should receive a Jetty error like this: image

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--
barkalinowski commented 1 year ago

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?

barkalinowski commented 11 months ago

Hi Ferdinando, I would like to remind you about problems we have. We still get 500: image