Developer forum

Forum » Integration » What's the point of having the request body on a connection endpoint in Endpoint management?

What's the point of having the request body on a connection endpoint in Endpoint management?

Imar Spaanjaars Dynamicweb Employee
Imar Spaanjaars
Reply

Hi there,

I am trying to understand how to use the Endpoint Manager for integration. I like the global concept of defining URL and credentials in a single location and then point to that configuration from my scheduled tasks.

It seems, however, that having the request body on the end point definition, rather than on the scheduled task, takes away that benefit. I was thinking it would work like this;

1. Create an endpoint called My Connection with a URL and credentials. This would be done only once.

2. Create a scheduled task to get users with a GetEcomData type="users" and select the end point My Connection to connect to the ERP

3. Create a scheduled task to get products with a GetEcomData type="products" and select the end point My Connection to connect to the ERP

4. Create more scheduled tasks  and select the end point My Connection to connect to the ERP

5. When we go live, change My Connection to point to the production ERP and be done.

 

However, it seems to be like this instead:

1. Create an endpoint called My Users Connection with a URL and credentials. Add GetEcomData type="users" as the request body.

2. Create an endpoint called My Products Connection with a URL and credentials. Add GetEcomData type="products" as the request body.

3. Create more endpoints with a URL, authentication and a request body

4. Create a scheduled task to get users and select the end point My Users Connection to connect to the ERP

5. Create a scheduled task to get products and select the end point My Products Connection to connect to the ERP

6. Create more scheduled tasks select the associated end point to connect to the ERP

7. When we go live, go to each and every end point and change the URL and credentials.

Wouldn't it make more sense to have the end point manage the URL and credentials only and have the request data still on the scheduled task? The end point would be the same for all, but the request would be different per scheduled task.

Before the end point manager, changing to a production URL (just an example) would mean we would have to visit and update each live integration scheduled task. In the new way I have to visit and update each end point instead (of which I need just as many as I previously needed scheduled tasks), so what's the advantage of the end points?

I think I am missing something obvious but I am not seeing it smiley

Thanks!

Imar

 


Replies

 
Dmitriy Benyuk Dynamicweb Employee
Dmitriy Benyuk
Reply

Hi Imar,
it works exactly as you need but only in case if it connects to a standard Dynamicweb web service exposed from the NAV/BC/AX/FO
Try to check the checkbox shown on the picture below.
Then the Body is set to empty <GetEcomData> request and is overriden when you create a new scheduled tasks using Import/Export data with custom request add-ins:

I am not sure if this behavior should be common for not a standard services, this can be considered/discussed.

Kind regards, Dmitrij

 
Imar Spaanjaars Dynamicweb Employee
Imar Spaanjaars
Reply

When I set it up like that, where do I then specify the custom request XML? I see this when I create a scheduled task using that end point:

 

So I can point it to my end point as I would expect but I don't see how to specify the XML that I could when I am not using an end point:

 

 

I would expect the Web service URL and Security key be hidden (as they come from the end point) with the Request XML still available...

Thanks!

 
Imar Spaanjaars Dynamicweb Employee
Imar Spaanjaars
Reply

Bump. Is there a way to specify the custom XML? If not, the end point tool is almost useless to me, as it means I now need to manage a URL + Key + XML on the end point  for each unique version, instead of on the scheduled task. Can this be redesigned a bit to allow the XML on the scheduled task, along with a selected end point?

Thanks!

 
Imar Spaanjaars Dynamicweb Employee
Imar Spaanjaars
Reply

Bump @Dmitriy any ideas on whether this can and should be improved? Thanks!

 
Dan Kristensen Hørlyck
Dan Kristensen Hørlyck
Reply

Hi Imar,

Endpoint Management was built with three main goals in mind:

  1. Be able to connect directly with a SaaS-version of D365 Business Central (without using Connector Service).
  2. Become ready for D365 Business Central OData, where each entity is a separate endpoint.
  3. Allow users to multi-edit base URL and authentication for each endpoint as you move from development to staging to production.

The end goal for Endpoint Management is not to improve upon the experience of using the SOAP web service exposed by our plug-in units, except for the ability to connect directly with the ERP.

Our long term goal is to move away from using the plug-in units. OData can do much more.

You do not have to use Endpoint Management. The "old" process still works like this:

  1. You use the Test Tool to send a request XML.
  2. You save the XML response somewhere in Files/Integration.
  3. You create a data integration activity and map from response XML to a table in DW (XML Provider as source, Dynamicweb Provider as destination*).
  4. You save and/or run the data integration activity.
  5. You create a batch integration job with scheduled task add-in for custom request**.
  6. You copy/paste the request XML from step 1 into the scheduled task and you reference the activity saved in step 4.
  7. You do not worry about credentials as they are added one place in the config file of the Connector Service.

Scheduled tasks/batch integration jobs can also be saved as XML so you can edit relevant parameters in a text editor or IDE, i.e. you can edit multiple, reuse across solutions (dev, stage, prod).

Your feature request is a great suggestion, but it is all a priority game. We need to continue investing in Endpoint Management to make OData a success, not SOAP. Right now we are refining query parameters, so Endpoint Management can function like a Postman-lite tool and filter data to manipulate the response. We are also adding OAuth support because D365 Business Central (SaaS) will require it in April 2021.

I hope I have covered everything. Feel free to get back to me if I missed something :-)

*) Or Ecom Provider in case of D365FO
**) Or scheduled task add-in with paging for the plug-in units which support paginating the response.
 
Sincerely,
Dan

 

You must be logged in to post in the forum