New Feature

TransmissionId for incoming messages

A new type of Duplicate Check

Transmission Id is a new ID which is unique for an interchange (Interchange In and Interchange Out).
It means that for a document going through Link, there will be a Transmission Id for the Ingoing Interchange and a Transmission Id for the Outgoing Interchange.

Transmission Id comes out of a need from AS4.
In the AS4 SOAP Header, there is a Message ID, that is used for duplicate detection for incoming documents. The AS4 Message ID is mapped to Transmission ID for Interchange In.
The Duplicate Detection is implemented in Link. That means that Link will reject an incoming document with a Transmission ID same as a previous incoming document with the same Transmission ID.

Transmission ID versus Interchange ID

Transmission ID and Interchange ID is similar to each other, because they both are related to Interchange. Interchange ID is an Id that is created by Link for each Interchange, one for the Interchange In and one for the Interchange Out. When a document is Resend in Link, it gets new Interchanges Id's, and that is the difference to Transmission ID. When a document is Resend in Link, Transmission ID stays the same.

Resending

By pressing the 'Resend' button, you will get different opportunity when resending the message.
About Disasssembling
The step from Interchange In to Message In is called disassembling.
The Interchange Infile is the file that arrived to Link.
If the Interchange In file is a batch file, it will be de-batched in the disassemble step.

Plain resend

If you don't mark any of the options, the Message In will be resend. (Look at the first screen dump to see where Message In is in the flow)

Resend by interchange

If you mark Resend by interchange, and resending the document(s) the flow will start at from the beginning with the disassembling step. If the incoming file is a batch of documents, the batch will be disassembled and all the document will go through Link again. 

Resend bypass doublet check

If you mark Resend bypass doublet check, the duplicate check will not be executed on this message. That means that although there is a duplicate message to the resend message, you will not get a duplicate error.

Resend bypass test marking

If you mark Resend bypass test marking the document will be processed even though it is test marked. E.g. has Edifact a test mark property.

Resend by document log

The name should have been Resend with document log.
If you mark Resend by document log, an extended logging will be done. This log is called Document Log. This feature is mainly for the developer, who is debugging.

Resend generate new transmission Id

If you mark Resend generate new transmission Id, a new Transmission Id will be generated on the outgoing interchange, which might prevent the receiver from detecting duplicates.

Resend related new permissions

• Tracking_Action_ResendUseDocumentLog
• Tracking_Action_ResendByPassTestMarking
• Tracking_Action_ResendByPassDoubletCheck
• Tracking_Action_ResendGenerateNewTransmissionId
• Tracking_Action_ResendByInterchange

To see the permissions, go to Settings->Roles, click Edit on a random role and click in the Permissions field:

Link monitor item to a pre-defined time schedule

Being able to differentiate between the severity of errors. (Scenario: Should a given error be handled during work hours or should it be handled immediately).

The problem

Today, the possibility is to either use threshold values or service windows status.
Threshold is not a valid solution, since it is applied all the time.
Service window is not a valid solution because
(A) if the last status from the item is failed, it will stay failed.
(B) Sometimes you might want the monitor item to be executed to notify the stakeholder or execute the action on errors.
Solution would be to on Item Level be able to register whether this is something to react on in normal working hours or 24/7. (Static SLA is good for now, but considerations of possibility to create different SLA like, 24/7, 24/5 etc. should be considered).

Solution Comment:

Reuse Scheduling functionality from Alerts to make it possible to create schedules for SLAs.
Make it possible to choose a SLA schedule for a monitor Item (and not for the group).
When a monitor item is linked to a Schedule (e.g. Normal Working Hours) it should be possible to choose if the Stakeholder notification on the group should still be triggered
The Monitor Xml should include info about if the item is within a time schedule or not (Boolean)
SMS Service should be extended to only send SMS if with a time schedule.

Option of enabling auto refresh on "Chart" page

If you want to use the Link graph page for TV screen, it is nice to have the option of auto refresh.

JSON - New format types

Ingoing JSON file

The EdiPortalReceive Component can now identify a JSON file.
An incoming JSON will be disassembled by the standard Biztalk JSON disassembler.

Outgoing JSON file

An outgoing JSON file will be assembled by the standard Biztalk JSON assembler.

New EHF validation must be implemented

There is a new Schematron validation from EHF.
Our validator is now updated with the new EHF validation.
The changes include combining of 'NOGOV-UBL-xxx.sch' and 'NONAT-UBL-xxx.sch' into 'EHF-UBL-xxx.sch'.
Some new "basic" validation rules have also been added, these rules are identified as 'EHF-TXX-BXXXXX'.
These new validation rules are expected to be updated to trigger error in next release.
A zip file containing the new schematron files can be found here:
https://test-vefa.difi.no/ehf/g2/files/schematron.zip
Note that the Schematron files are made for XSLT 2.0.

Better link-handling when opening a link in a new tab or window

We have improved two Links.
The two links are Ingoing Partner and Outgoing Partner on Tracking Search Details page.
For the two links improved links we are now using our own component<ep-link>, instead of standard <a>.
The improvement, that <ep-link> adds, is that when you are opening a new window by right click on the link, the link has the DataOwnerGuid in the URL, which is needed for a successful new window.

Stream handling of large files

When Link is receiving large files, our implementation can get into trouble.
The problem is when we are loading the whole file into memory and the file is too big for that.
(Loading into memory when you e.g. are using Byte Array(byte[]) and XmlDocument)
A solution is to handle the file in a stream instead of loading the file into memory.
We have therefore listed all the places in our implementation, where we load files into memory to get an overview of where can get into trouble.
We have refactored four important steps/functionalities, where we have replaced the 'in memory'-way of handling files, with 'stream'-way of handling files.
The four steps/functionalities, where we now are using a stream, is

• Backup Files
• Read xpath at TrackCdm-itinerary
• Read xpath macro functionality
• Check for empty length files

Show additional information in userinterface

Because there is additional information, that wasn't in use, we have added as tooltips different places, like

• Error-description on Error Handling page
• Document Type description on Document Type tab, Tracking Search Result page
• Document Group description on Document Group, Tracking Search Result page
• Format description on From and To Format, Distribution pages
• ID Qualifier description on Identification page, Partner page

Pre-installation-analysis

A new tool, that can analyze different issues, that can be a problem for the Installer.

Bring the BizTalk installation PDF document up-to-date (#280208753)

There is an installation guide in the folder that Octopus creates. These Installation Guide is now updated.

TransmissionId for incoming messages

TransmissionId is a new ID.
There can be TransmissionId for Ingoing Interchange and Outgoing Interchange, but it is optional.
When a Messages comes via AS4, the Message Id from the AS4 SOAP Header, will be the Ingoing Interchange Transmission Id.
There will always be generated a TransmissionId for Outgoing Interchange.
And here comes a thing that makes TransmissionId different from the other IDs. TransmissionId will be the same, when are you resending the messages. Unless you mark the Resend generate new transmission Id -option, when you are resending.
You will see TransmissionId

• As a search field on Tracking Search (under Advanced Search)
• On Tracking Search Detail
• On Resend popup dialog
• New permission: Tracking_Action_ResendGenerateNewTransmissionId

All adapters will be installed when you do a clean install (A Installer-feature)

The Installer will now install all adapters, so you don't have to install adapters manually.
Adapters that is present:

• EdiPortal
• EdiPortalAS2
• EdiPortalAS4
• EdiPortalLocalFTP
• EdiPortalSFtp
• Passthrough

AS4 - Error Codes

There is now a AS4 specific error-codes for the errors that can occur in AS4.

• 18000AS4CompressionException A error has occurred while compressing or decompressing
• 18001AS4EncryptionExceptionThe encryption data has some some missing data. See error text for more detail.
• 18002AS4MissingCertificateExceptionNo certificate is found
• 18003AS4SerializeExceptionNo serializer found for response content-type
• 18004AS4SigningExceptionAS4 Signing Exception
• 18005AS4PayloadRetrieverExceptionNo interchange out is found
• 18006AS4PModeExceptionNo PMode found
• 18007Unknown AS4 unknown transport error
• 18100Unexpected error receivingUnexpected error has occurred while receiving AS4 message
• 18101AS4Handler ExceptionAS4Handler Unknown Exception
• 18102ParsingError An error has occurred while parsing the incoming message
• 18103ProfileValidationErrorIncoming message failed profile-validation
• 18104SignalMessageErrorA error occurred in the primary signal message
• 18105PartnerORDataOwnerMissingNo valid partner or dataowner found for receiver
• 18106NoAttachment No attachments found for usermessage

Authentication in the Monitor service against the EDI Portal webservice

It has until now, been possible to call the Monitor Service with Anonymous authentication. That is a security problem, that we now have changed.
Anonymous authentication is disabled.
Monitor service now needs to authenticate with a Link user.
There is a permission which is applied both for AD and Link user authentication.
JSON file for monitor install is enhanced, to include Link User and password in case you are not using AD authentication.
On both clean install and upgrade creates a MonitorService Role and a MonitorServiceGroup with that role and a MonitorServiceUser if it is not AD authentication.