Infor M3 REST
The M3 Rest Connector is used to execute transactions in M3 via the M3-API-REST bulk API.
Configuration
Url Required url to base address of REST API.
Design time Authentication In this section the authentication to be used when fetching metadata from the REST API is configured. User name (basic) and Password (basic) is used for Basic Authentication, as specified in RFC2617. The information in this section is only used while designing workflows in Flow Studio. It is never used in runtime. The user specified here must be allowed to run the transactions LstPrograms, LstTransactions and LstFields in the program MRS001MI. In this section there is also the possibility to accept any certificate from server in an https session. This should only be used for test or development scenarios when no other option exists.
Runtime Authentication In this section the authentication to be used when executing machine tasks is configured. User name (basic) and Password (basic) is used for Basic Authentication, as specified in RFC2617. In this section there is also the possibility to accept any certificate from server in an https session. This should only be used for test or development scenarios when no other option exists.
Logging In this section logging is configured. Either incoming or outgoing or both can be logged. If something goes wrong in the communication, an entry is added to the file errorLog.txt. In order to enable logging, a valid path relative to the Flow Server must also be provided. Note that the path must already exist, the connector will not create the path. Also note that the user that Flow Server is running as must have write access to the path.
Get started
Press Select operation to select which transaction to execute.
Input
The input will of course depend on the transaction to execute. There is one common parameter that always is available though, readtimeoutmillis. In this parameter you can specify the amount of time to wait for response from job.
Another common feature for all transactions is the possibility to use an iterator. If you select a iterator it means that the transaction will be executed once for each row in the table specified as iterator. Using a iterator will change the output of the cogwheel to a table with the same number of rows as the iterator table, each row in the table is corresponding result of transaction execution for row in iterator table. You can of course map columns in iterator to parameters of transaction. Simply select an iterator, and for a parameter select I Iterator in dropdown menu for parameter and then select the suitable column of iterator table.
Output
Record (or table of records if iterator is used).
Member | Description |
HttpStatusCode | The status code returned from REST API. Typically 200 if request (not necessarily transaction) was successful. 401 if not authorized etc. |
ReasonPhrase | HTTP ReasonPhrase, if any |
AllHeaders | Simple variable containing all headers (with line feed between each header) returned by REST API. |
OK | A record containing result of transaction if it was successfully executed. Will be empty if transaction failed. - Program - Simple variable containing the program executed - Transaction - Simple variable containing the transaction executed - Records - A table containing the records (if any) returned by transaction. The columns of the table will of course depend on the transaction, but you can always choose not the request particular columns by unchecking the Included checkbox. By doing that, it will not be requested from the REST API, which could boost performance. You can also specify a row limit on Records (default 100). |
Error | A record containing error information if transaction failed for some reason. Will be empty if transaction was successfully executed. |
Note that if HttpStatusCode is 200, either OK or Error (never both) contains data. This can be used to take different paths in your workflow. Simply add a 'Decision Step' and add a script rule like transactionResults.Error != nil to check for errors.
Last updated