Creation of an Outbound Delivery in Apps 10



Important note:

As the term of the BnT backup (point. 1.2.4 ) is extremely long (approx. 2-3 hours), you should initiate this 1-2 days before the start of delivery.

Delivery in the LCS

Create new delivery ID

The structure of the delivery ID should be as follows (for all new customers):

PG+NNN (three-digit numeric).0 or .1 or .2 for correction deliveries


These are created either via the "+" at the top right or via the menu using the duplicate function. For older projects, there is often no ".0" and ".1" at the end. However, this makes sense for new customers who have a fixed delivery schedule, as otherwise the order and number communicated to the customer would get mixed up in the event of corrections.

Create delivery:


set the created delivery to OPEN:

Compile delivery

Switch to the "Service Center" delivery


Determine which parcels are to be delivered:



The parcels awaiting delivery are pushed to the new delivery.


Set all packages to "Ready":


Change delivery status

The delivery is now closed (this is only possible when all parcels are set to "Ready"):


Generate Harvest Extractor File

Now extract the delivery from the harvest ("Generate Harvest Extractor File"):

Always select "K:\_Deliveries" as the storage location first!

Control UPG, CRE

Check whether UPG or CRE are included. Then reject the package and return it to the developer.

IFS Solution Developer (ISD)

open after saving:

alternatively double-click on Extractor File:

Display of all files included in the delivery:


 

Check Harvest Bypass

RMB "Check Harvest Bypass" must always be used to check whether any program versions are bypassed by the delivery.

possible result:


è Save log via ByPass:


Example:


version 1ß delivered

version 4ß not delivered

versions 2, 3 and 5ß are to be delivered now

 

The "Check Harvest Bypass" function would therefore report that version 4 of this file has not yet been delivered and is "bypassed" by the current delivery.

The status "Build & Test" for the files of the current delivery is only visible AFTER the promote, but helps when processing the ByPass. It is therefore best to perform the ByPass check first, then promote, then merge the ByPass files.

Desirable result of the check:


The bypass check only needs to be carried out once, it runs the same for all files in the delivery (not just for the selected one).

Treatment ByPass

If the Harvest Bypass produces a file list as a result:

LNG, TRS and terms can generally be ignored

All other files:

-        Check whether a skipped package can perhaps be delivered after all

-        if not: merge or the delivery will be postponed!

If you decide to merge (depends on how urgent the delivery is and whether you can wait for the rest):

The aim is to ensure that only those adaptations / changes are supplied that are actually intended to be supplied.

 Promote

(Provided the delivery is carried out)

Now the packages in Harvest must be moved from "Implementation" to "Build&Test" or "Test" using "Promote":


Harvest login (please use your own user):


the packages are now set to "Build&Test":

ATTENTION: after "Promote", close the window with "Close". It will not close by itself! Do not click on "Promote" again, otherwise the status will be increased even further!

After "Close", the display in the Solution Developer is updated:



Backup of the BnT

Before installation, make a backup of the BnT in order to reset it in the event of an error.






Wait until green.

Download

The download takes place after the bypass check. The delivery list is prepared for this:

K:_Deliveries

Back in the Solution Developer, the download is started via RMB:


To avoid problems with current or previous ByPass merges, the "Download Latest in View" checkbox should always be set:

This loads the latest version of the file from the current status (Build&Test).

Note: there is no "Original" folder in the Harvest download as a result

 

Build

The current cif(x) file must be loaded before the build:



The delivery is then built (BUILD).


"Deployment order based on file extension":

causes the sequence of program calls in the installation script to be created based on the file types and not according to modules (i.e. as before Apps8).

The build function is only possible after a download! The menu item is not active/visible beforehand.

If the following prompt appears, confirm it with OK.


This window appears after Build:



Build process:

After starting the build process, the following page opens, which shows the progress of the remote build:




http://lkpvmpe4867/BNT/mainprogress.html

Logfiles:

\\lkpvmpe4867\BNT_logs



It is essential to ensure that all points are completed without errors (green). The creation of the delivery is only complete when "End main" is displayed at the end.

The Solution Developer can then be closed

Structure of a delivery

Installation Files


The delivery directory contains the "InstallationFiles" folder, which contains the actual delivery.

The server files are stored under "Database". The installation is carried out via the tem files. The subdirectories contain the individual programs.

The folders next to "Database" (client, installer, server etc.) contain the ExtendedServer files.

Manual Installation

If there are files under ManualInstallation, these must be considered separately and a decision made as to whether they can be included in the installation scripts for the automatic run or must be installed manually.

Ifs.PackageManagement.exe / Ifs.DEV.PM.Utility.exe

No longer necessary.

Parameter entries may be required in the installation programs. To automate this, the required parameters can be determined using Ifs.PackageManagement.exe or Ifs.DEV.PM.Utility.exe:



The parameters determined are copied to the define.tem file:


This procedure is necessary for versions smaller than Apps8. From Apps8 onwards, the input parameters are maintained via deploy.ini.

Installation on the BnT

Goto relevant VM

Stop managed-servers before instalation

Goto ifs_home location and run installer.cmd as admin and proceed with remaining steps.



Give the instalation files path as instalation folder when needed.


Check whether it has been installed.

select * from module_tab t WHERE t.description='DELIVERY' ORDER BY t.reg_date


Finalize delivery

LCS - Change status

Once the delivery has been successfully installed on the internal BNT identifier (including checking the logs and testing the login to IFS EE), the delivery is "upgraded" in the LCS:


Note:

the status in the LCS cannot be reversed!

FTP

The entire delivery is zipped and copied to the FTP server

 


Log in with your own Windows login:

Copy delivery:


The customer has access to this FTP directory and collects the delivery.

 

Prepare delivery bill and e-mail

This step only needs to be done once per customer.

Attention this template cannot be deleted or edited

Create delivery bill


Exclude Duplicate Lines

For each case included in the delivery, only one line is displayed in the delivery bill, regardless of how many Harvest packages are behind it (if there are several customization packages with different Ebod notes for a case, several items are created on the delivery bill)

Template name

A predefined template can be selected here. In this example, it is the installation on the BNT, the actual delivery to the customer takes place later. The template "PRE" is therefore selected.

New Bill Id

Designation of the delivery bill. Can be freely assigned. In this case with the prefix "PREL_", as this is a provisional delivery bill.


Result:



The "Include in BoD" column shows whether the line is visible on the customer delivery bill (BoD). If "Exclude Duplicate Lines" was forgotten when the delivery bill was created, it can still be added in this screen. Individual items can also be included or excluded:

 

Send delivery info

As soon as the delivery bill is completed, it is sent to the customer or, as in this case, to the project team:


After selecting the template, the form is filled:


The content of the text should be checked again! (does it really fit for this delivery?)

The "Published" tick must be set individually depending on the message. For advance or internal deliveries, it is advisable not to check the box, as a new delivery bill is created for the final delivery and the link to the published delivery bill becomes invalid.

The "Attach eBOD" checkbox should always be selected. This will attach the delivery bill as a pdf file to the email notification.


LCS - Close delivery tasks

To inform the case owner that an adjustment or bugfix has been delivered, the delivery task must be processed. I.e. for each individual task accept - (complete) - close

In addition, information should be provided for "Complete"/"Close":

"Delivered with PGXXX on <date>. Customer installs himself"

resp.

"Delivered and installed on <database> with PGXXX on <date>. Customer is informed."

Reworking

Move Harvest Exctractor files


If the customer has installed on the test, the PG must be moved to the next status "Release for Test" via Promote. To do this, double-click on the hewx file. Then click on any file RMB -> Promote


The same applies if it is then installed on the PROD.

Post a Comment

0 Comments