Hi Blommetje,

I think the error most be in your LINQPad script because you mention the following:

When I run the URL /api/iam/alias/work_order in Postman, I get the expected results. However, when I request this data in a LINQPad script, I receive data from a different table (document_pool).

Because it works from Postman, it is most likely something in your LINQPad script.

Can you also try to do this from your browser (if it is a simple GET request) and check if the result is what you expect? I would guess it would also show the correct data.

We might be able to help when you provide us the LINQPad script.

Hi Dick, 

Well, I have no clue on this. Postman works fine. However, the call in Linqpad remains inconsistent. 
Every now and then it works, but can’t find an obvious reason. Yesterday it worked on UAT. This morning it failed. Without any changes/deployments on that machine. 
The Linqpad is quite straightforward; Obviously the url/username/pass are modified. 

async void Main()
{
	var client = new ODataClient(new ODataClientSettings
	{
		BeforeRequest = request => request.Headers.Authorization = GetAuthorizationHeader(),
		//BaseUri = new Uri("https://linkgoeshere.com/API/iam/cff_lab"),
		BaseUri = new Uri("https://linkgoeshere.com/api/iam/cff_ep"),		
	});

		await client.For<work_order>()
		.FindEntriesAsync()
		.Dump();
}

internal static AuthenticationHeaderValue GetAuthorizationHeader() =>
new AuthenticationHeaderValue("Basic",
   Convert.ToBase64String(
	   Encoding.UTF8.GetBytes($"user:pass")));
public class work_order
{
	public long WorkOrderId { get; set; }
	public string WorkOrderNr { get; set; }	
}

The issue in both environments is that instead of getting data from the table work_order, we get (all) rows from the table document_pool. All other tables seem to work fine..  We do not get any errors, so technically it’s working.. 

Any thoughts on this? Caching? I’m on Indicium 2024.2.12. Are there any bugs solved related to this in the meantime? 

Blommetje

Have you considered putting in a Wireshark session to see the actual requests that are fired(and its replies)? It is (to me) very hard to believe that the actual request to work_order results in a resultset/reply from that request to document_pool… (no judgement here, just genuinely interested)

Hi Blommetje,

I do not have a Linqpad subscription, so I am not able to test this with Linqpad. It did however try it through Visual Studio and it looks oke. I did not have the issue yet, but I will try a bit more.

Some things to try:

Can you login to Indicium with the same user, and open the account/ui/dbEventLog page?

It shows the request URL as well - and probably you will see document_pool instead of work_order.

That won’t help finding a solution, it will just make it more clear that Indicium is receiving a request for document_pool instead of work_order.
 

Another guess, I wonder if for some reason the ODataClient has difficulties with the metadata.

When you open https://linkgoeshere.com/api/iam/cff_ep/$metadata

Is document_pool by any chance the first “EntityType”? (Please ignore the FileContract and “ProcessActionContextType” that are probably first listed that as ComplexTypes in the metadata.)
 

What happens if you instead of client.For<work_order> use

await client.FindEntriesAsync(“work_order”).Dump()?

Hi ​@Blommetje,
Any updates on this? :)

HI,

We no longer use OData for data retrieval; instead, we use RestSharp. The main advantage we've noticed is significantly better performance. We suspect there might be something odd with the OData client, but we're not sure what it is. It wasn't worth the effort to investigate further.

Blommetje