REST API Register Arrival

Hi Ilari,

What projections did you try and how did you try to call them, and with what data?

Can you easily do in the client whatever you want to do with a program? If yes, what are the steps? (I don't know that functionality).

Thanks!

Hi Mathias, 

Thanks for your input.

Yes, I can easily do the same in client:

1.Purchase Order in status ‘Released’.

2.In ‘Register Arrival’ -window, search for that PO, ‘RMB’ and click ‘Receive’. 

3.Purchase Order should be in status ‘Received’ and receipt should be done.

That step 2 is what I want to achieve with REST API.

So, I tried to do that with following projections:

• PurchaseOrderLinesHandling
  • With this I am able to change the PO status to ‘Received’, but no receipt was actually made. So it is only changing the status without receiving
• RegisterArrivals
  • This ends up in error ‘The key value ‘SourceRefType’ is invalid.
  • In the API Explorer it says this should be ‘PurchaseOrder’, in database it is ‘PURCHASE_ORDER’, neither works. 
• CreateReceipt
  • This has no parameters in the header, so unable to match the PO
  • Other call methods has a parameter ‘ObjKey’, but they are not visible.
    • When calling with GET -method, I get some records, but not the PO’s that I want to receive.

Best Regards,

Ilari

@ilarirossi 

Hi again,

Sorry for not coming back until now.

In your case above you are using an assistant to do a certain operation. Many assistants can be quite tricky to "replicate" using REST calls in many cases. An action call from a normal page is always easy to replicate since all information is there in one call in the Network tab in Chrome's Dev Tools.

The main reason for assistants being tricky to handle is that we often work with "virtuals" there. A virtual is a kind of fake LU, or entity, only meant to be used for storing data temporarily during the lifetime of the assistant. Many assistants start by creating a virtual record to keep the information necessary to execute the final action in the end. This record often contains a mix of data from the database and from data entered by the user. An assistant does not have to use virtuals though, and those are often easier to replicate. And even if they do, sometimes what happens during to the virtual during the flow of the assistant is then just used in a "normal" action call in the end. But sometimes, the virtual/record itself is used in the action call.

So, I think there are three main ways in how an assistant executes the final action:

- Not using virtuals, and using a "normal" action call, with one parameter for each value needed
- Using virtuals, but using a "normal" action call in the end
- Using virtuals and using the virtual as the bearer of information in the action call at the end

In the first two cases, you only need to look for the POST request that happens when you finish the assistant. There you should see the full URL of the action as well as the data sent in to it. This should be easy to replicate in any REST client/tool.

The tricky case is the third one, where the virtual/record is what is used by the action. Here you cannot see individual parameters used by the action. Instead the action is just executed with the virtual/record that keeps all the information the action needs. To replicate this scenario you must play along and create the virtual, get a handle to the virtual (getting it's objkey), update the virtual and, in the end use the virtual in the action call. It's not hard, really, and after doing it a few times you will get the hang of it. Everything we need is in the Network tab under Chrome's Dev Tools. But it's messier than in the first two cases.

Luckily, R&D have a lot of integration tests (look in the INTTST component) that does all of this already and most probably our demo show room scripts does too, so there should be examples to look at there as well.

Lastly, to take your case an an example, let's see what is probably the important calls of the assistant you used there:

Here is probably where that virtual is created:

Here is the payload/data sent to the action:

Here is the result:

Note the objkey there, which will probably be used in other calls:

Here is a POST call that can be ignored because it has nothing to do with what you want to do:

Here is some manipulation (an action call) of the virtual record created earlier:

Here is probably the action call that does the stuff in the end:

Here we can see that the only input to that action call is the ID/key of the virtual (which is why we need to created it too in order to replicate what happens):

Yeah, that is probably it.

So... You can achieve anything that the Aurena client does, you only need to find all the relevant calls, and working with virtuals complicates that, sometimes (not always). If you can find a page that does a "normal", or simpler call, you probably want to do that before you go down the virtuals path. In some cases there is no alternative though and those might be the cases where you could kindly ask R&D to build a nicer integration API/projection.

I hope this was at least some help.

Good luck!
 

@ilarirossi 

Were you able to access the recording? Also, did the explanations above help?

Hi @Mathias Dahl, I didn’t have time to check the recording yet, but your instructions were good enough.

So I tried with postman and first created the virtual (CreateReceipSet) and got the objkey. Then used that objkey to do the actual command which does the receipt (CreateArrivalReceipt). I ignored the parts in between.

It worked and was actually quite simple to do. Thanks a lot again and I actually think quite many operations in IFS seems to be using these virtuals, so this will helpful in the future as well. 

Thanks for reporting back, I’m glad you found it useful and hope others will too 😀💪🏻